[JSC] Remove !(OS(LINUX) && CPU(ARM64)) guards in RegisterState.h
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2017-10-22  Zan Dobersek  <zdobersek@igalia.com>
2
3         [JSC] Remove !(OS(LINUX) && CPU(ARM64)) guards in RegisterState.h
4         https://bugs.webkit.org/show_bug.cgi?id=178452
5
6         Reviewed by Yusuke Suzuki.
7
8         * heap/RegisterState.h: Re-enable the custom RegisterState and
9         ALLOCATE_AND_GET_REGISTER_STATE definitions on ARM64 Linux. These don't
10         cause any crashes nowadays.
11
12 2017-10-22  Yusuke Suzuki  <utatane.tea@gmail.com>
13
14         [JSC][Baseline] Use linkAllSlowCasesForBytecodeOffset as much as possible to simplify slow cases handling
15         https://bugs.webkit.org/show_bug.cgi?id=178647
16
17         Reviewed by Saam Barati.
18
19         There is much code counting slow cases in fast paths to call `linkSlowCase` carefully. This is really error-prone
20         since the number of slow cases depends on values of instruction's metadata. We have linkAllSlowCasesForBytecodeOffset,
21         which drains all slow cases for a specified bytecode offset. In typical cases like just calling a slow path function,
22         this is enough. We use linkAllSlowCasesForBytecodeOffset as much as possible. It significantly simplifies the code.
23
24         * jit/JIT.h:
25         (JSC::JIT::linkAllSlowCases):
26         * jit/JITArithmetic.cpp:
27         (JSC::JIT::emitSlow_op_unsigned):
28         (JSC::JIT::emit_compareAndJump):
29         (JSC::JIT::emit_compareAndJumpSlow):
30         (JSC::JIT::emitSlow_op_inc):
31         (JSC::JIT::emitSlow_op_dec):
32         (JSC::JIT::emitSlow_op_mod):
33         (JSC::JIT::emitSlow_op_negate):
34         (JSC::JIT::emitSlow_op_bitand):
35         (JSC::JIT::emitSlow_op_bitor):
36         (JSC::JIT::emitSlow_op_bitxor):
37         (JSC::JIT::emitSlow_op_lshift):
38         (JSC::JIT::emitSlow_op_rshift):
39         (JSC::JIT::emitSlow_op_urshift):
40         (JSC::JIT::emitSlow_op_add):
41         (JSC::JIT::emitSlow_op_div):
42         (JSC::JIT::emitSlow_op_mul):
43         (JSC::JIT::emitSlow_op_sub):
44         * jit/JITArithmetic32_64.cpp:
45         (JSC::JIT::emit_compareAndJumpSlow):
46         (JSC::JIT::emitSlow_op_unsigned):
47         (JSC::JIT::emitSlow_op_inc):
48         (JSC::JIT::emitSlow_op_dec):
49         (JSC::JIT::emitSlow_op_mod):
50         * jit/JITCall.cpp:
51         (JSC::JIT::compileCallEvalSlowCase):
52         (JSC::JIT::compileOpCallSlowCase):
53         * jit/JITCall32_64.cpp:
54         (JSC::JIT::compileCallEvalSlowCase):
55         (JSC::JIT::compileOpCallSlowCase):
56         * jit/JITInlines.h:
57         (JSC::JIT::linkAllSlowCasesForBytecodeOffset):
58         * jit/JITOpcodes.cpp:
59         (JSC::JIT::emitSlow_op_new_object):
60         (JSC::JIT::emitSlow_op_create_this):
61         (JSC::JIT::emitSlow_op_check_tdz):
62         (JSC::JIT::emitSlow_op_to_this):
63         (JSC::JIT::emitSlow_op_to_primitive):
64         (JSC::JIT::emitSlow_op_not):
65         (JSC::JIT::emitSlow_op_eq):
66         (JSC::JIT::emitSlow_op_neq):
67         (JSC::JIT::emitSlow_op_stricteq):
68         (JSC::JIT::emitSlow_op_nstricteq):
69         (JSC::JIT::emitSlow_op_instanceof):
70         (JSC::JIT::emitSlow_op_instanceof_custom):
71         (JSC::JIT::emitSlow_op_to_number):
72         (JSC::JIT::emitSlow_op_to_string):
73         (JSC::JIT::emitSlow_op_loop_hint):
74         (JSC::JIT::emitSlow_op_check_traps):
75         (JSC::JIT::emitSlow_op_has_indexed_property):
76         (JSC::JIT::emitSlow_op_get_direct_pname):
77         (JSC::JIT::emitSlow_op_has_structure_property):
78         * jit/JITOpcodes32_64.cpp:
79         (JSC::JIT::emitSlow_op_new_object):
80         (JSC::JIT::emitSlow_op_instanceof):
81         (JSC::JIT::emitSlow_op_instanceof_custom):
82         (JSC::JIT::emitSlow_op_to_primitive):
83         (JSC::JIT::emitSlow_op_not):
84         (JSC::JIT::emitSlow_op_stricteq):
85         (JSC::JIT::emitSlow_op_nstricteq):
86         (JSC::JIT::emitSlow_op_to_number):
87         (JSC::JIT::emitSlow_op_to_string):
88         (JSC::JIT::emitSlow_op_create_this):
89         (JSC::JIT::emitSlow_op_to_this):
90         (JSC::JIT::emitSlow_op_check_tdz):
91         (JSC::JIT::emitSlow_op_has_indexed_property):
92         (JSC::JIT::emitSlow_op_get_direct_pname):
93         * jit/JITPropertyAccess.cpp:
94         (JSC::JIT::emitSlow_op_try_get_by_id):
95         (JSC::JIT::emitSlow_op_get_by_id):
96         (JSC::JIT::emitSlow_op_get_by_id_with_this):
97         (JSC::JIT::emitSlow_op_put_by_id):
98         (JSC::JIT::emitSlow_op_resolve_scope):
99         (JSC::JIT::emitSlow_op_get_from_scope):
100         (JSC::JIT::emitSlow_op_put_to_scope):
101         * jit/JITPropertyAccess32_64.cpp:
102         (JSC::JIT::emitSlow_op_try_get_by_id):
103         (JSC::JIT::emitSlow_op_get_by_id):
104         (JSC::JIT::emitSlow_op_get_by_id_with_this):
105         (JSC::JIT::emitSlow_op_put_by_id):
106         (JSC::JIT::emitSlow_op_resolve_scope):
107         (JSC::JIT::emitSlow_op_get_from_scope):
108         (JSC::JIT::emitSlow_op_put_to_scope):
109
110 2017-10-22  Yusuke Suzuki  <utatane.tea@gmail.com>
111
112         [JSC] Clean up baseline slow path
113         https://bugs.webkit.org/show_bug.cgi?id=178646
114
115         Reviewed by Saam Barati.
116
117         If the given op is just calling a slow path function, we should use DEFINE_SLOW_OP instead.
118         It is good since (1) we can reduce the manual emitting code and (2) it can clarify which
119         function is implemented as a slow path call. This patch is an attempt to reduce 32bit specific
120         code in baseline JIT.
121
122         * jit/JIT.cpp:
123         (JSC::JIT::privateCompileMainPass):
124         * jit/JIT.h:
125         * jit/JITArithmetic.cpp:
126         (JSC::JIT::emit_op_pow): Deleted.
127         * jit/JITArithmetic32_64.cpp:
128         (JSC::JIT::emitSlow_op_mod):
129         * jit/JITOpcodes.cpp:
130         (JSC::JIT::emit_op_strcat): Deleted.
131         (JSC::JIT::emit_op_push_with_scope): Deleted.
132         (JSC::JIT::emit_op_assert): Deleted.
133         (JSC::JIT::emit_op_create_lexical_environment): Deleted.
134         (JSC::JIT::emit_op_throw_static_error): Deleted.
135         (JSC::JIT::emit_op_new_array_with_spread): Deleted.
136         (JSC::JIT::emit_op_spread): Deleted.
137         (JSC::JIT::emit_op_get_enumerable_length): Deleted.
138         (JSC::JIT::emit_op_has_generic_property): Deleted.
139         (JSC::JIT::emit_op_get_property_enumerator): Deleted.
140         (JSC::JIT::emit_op_to_index_string): Deleted.
141         (JSC::JIT::emit_op_create_direct_arguments): Deleted.
142         (JSC::JIT::emit_op_create_scoped_arguments): Deleted.
143         (JSC::JIT::emit_op_create_cloned_arguments): Deleted.
144         (JSC::JIT::emit_op_create_rest): Deleted.
145         (JSC::JIT::emit_op_unreachable): Deleted.
146         * jit/JITOpcodes32_64.cpp:
147         (JSC::JIT::emit_op_strcat): Deleted.
148         (JSC::JIT::emit_op_push_with_scope): Deleted.
149         (JSC::JIT::emit_op_assert): Deleted.
150         (JSC::JIT::emit_op_create_lexical_environment): Deleted.
151         * jit/JITPropertyAccess.cpp:
152         (JSC::JIT::emit_op_put_by_val_with_this): Deleted.
153         (JSC::JIT::emit_op_get_by_val_with_this): Deleted.
154         (JSC::JIT::emit_op_put_by_id_with_this): Deleted.
155         (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval): Deleted.
156         (JSC::JIT::emit_op_define_data_property): Deleted.
157         (JSC::JIT::emit_op_define_accessor_property): Deleted.
158         * jit/JITPropertyAccess32_64.cpp:
159         (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval): Deleted.
160         (JSC::JIT::emit_op_get_by_val_with_this): Deleted.
161         (JSC::JIT::emit_op_put_by_id_with_this): Deleted.
162         (JSC::JIT::emit_op_put_by_val_with_this): Deleted.
163
164 2017-10-21  Joseph Pecoraro  <pecoraro@apple.com>
165
166         Web Inspector: Remove unused Console.setMonitoringXHREnabled
167         https://bugs.webkit.org/show_bug.cgi?id=178617
168
169         Reviewed by Sam Weinig.
170
171         * JavaScriptCore.xcodeproj/project.pbxproj:
172         * Sources.txt:
173         * inspector/agents/InspectorConsoleAgent.h:
174         * inspector/agents/JSGlobalObjectConsoleAgent.cpp: Removed.
175         * inspector/agents/JSGlobalObjectConsoleAgent.h: Removed.
176         * inspector/protocol/Console.json:
177         Removed files and method.
178
179         * inspector/JSGlobalObjectInspectorController.cpp:
180         (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
181         This can use the base ConsoleAgent now.
182
183 2017-10-21  Yusuke Suzuki  <utatane.tea@gmail.com>
184
185         [JSC] Remove per-host-function CTI stub in 32bit environment
186         https://bugs.webkit.org/show_bug.cgi?id=178581
187
188         Reviewed by Saam Barati.
189
190         JIT::privateCompileCTINativeCall only exists in 32bit environment and it is almost the same to native call CTI stub.
191         The only difference is that it embed the address of the host function directly in the generated stub. This means
192         that we have per-host-function CTI stub only in 32bit environment.
193
194         This patch just removes it and use one CTI stub instead. This design is the same to the current 64bit implementation.
195
196         * jit/JIT.cpp:
197         (JSC::JIT::compileCTINativeCall): Deleted.
198         * jit/JIT.h:
199         * jit/JITOpcodes.cpp:
200         (JSC::JIT::privateCompileCTINativeCall): Deleted.
201         * jit/JITOpcodes32_64.cpp:
202         (JSC::JIT::privateCompileCTINativeCall): Deleted.
203         * jit/JITThunks.cpp:
204         (JSC::JITThunks::hostFunctionStub):
205
206 2017-10-20  Antoine Quint  <graouts@apple.com>
207
208         [Web Animations] Provide basic timeline and animation interfaces
209         https://bugs.webkit.org/show_bug.cgi?id=178526
210
211         Reviewed by Dean Jackson.
212
213         Remove the WEB_ANIMATIONS compile-time flag.
214
215         * Configurations/FeatureDefines.xcconfig:
216
217 2017-10-20  Commit Queue  <commit-queue@webkit.org>
218
219         Unreviewed, rolling out r223744, r223750, and r223751.
220         https://bugs.webkit.org/show_bug.cgi?id=178594
221
222         These caused consistent failures in test that existed and were
223         added in the patches. (Requested by mlewis13 on #webkit).
224
225         Reverted changesets:
226
227         "[JSC] ScriptFetcher should be notified directly from module
228         pipeline"
229         https://bugs.webkit.org/show_bug.cgi?id=178340
230         https://trac.webkit.org/changeset/223744
231
232         "Unreviewed, fix changed line number in test expect files"
233         https://bugs.webkit.org/show_bug.cgi?id=178340
234         https://trac.webkit.org/changeset/223750
235
236         "Unreviewed, follow up to reflect comments"
237         https://bugs.webkit.org/show_bug.cgi?id=178340
238         https://trac.webkit.org/changeset/223751
239
240 2017-10-20  Yusuke Suzuki  <utatane.tea@gmail.com>
241
242         Unreviewed, follow up to reflect comments
243         https://bugs.webkit.org/show_bug.cgi?id=178340
244
245         * runtime/JSModuleLoader.cpp:
246         (JSC::JSModuleLoader::notifyCompleted):
247
248 2017-10-20  Saam Barati  <sbarati@apple.com>
249
250         Optimize accesses to how we get the direct prototype
251         https://bugs.webkit.org/show_bug.cgi?id=178548
252
253         Reviewed by Yusuke Suzuki.
254
255         This patch makes JSObject::getPrototypeDirect take VM& as a parameter
256         so it can use the faster version of the structure accessor function.
257         The reason for making this change is that JSObjet::getPrototypeDirect
258         is called on the hot path in property lookup.
259
260         * API/JSObjectRef.cpp:
261         (JSObjectGetPrototype):
262         * jsc.cpp:
263         (WTF::DOMJITGetterBaseJSObject::DOMJITAttribute::slowCall):
264         (WTF::DOMJITGetterBaseJSObject::customGetter):
265         (functionCreateProxy):
266         * runtime/ArrayPrototype.cpp:
267         (JSC::speciesWatchpointIsValid):
268         * runtime/ErrorInstance.cpp:
269         (JSC::ErrorInstance::sanitizedToString):
270         * runtime/JSArray.cpp:
271         (JSC::JSArray::isIteratorProtocolFastAndNonObservable):
272         * runtime/JSGlobalObject.cpp:
273         (JSC::JSGlobalObject::init):
274         (JSC::lastInPrototypeChain):
275         (JSC::JSGlobalObject::resetPrototype):
276         (JSC::JSGlobalObject::finishCreation):
277         * runtime/JSGlobalObjectInlines.h:
278         (JSC::JSGlobalObject::objectPrototypeIsSane):
279         (JSC::JSGlobalObject::arrayPrototypeChainIsSane):
280         (JSC::JSGlobalObject::stringPrototypeChainIsSane):
281         * runtime/JSLexicalEnvironment.cpp:
282         (JSC::JSLexicalEnvironment::getOwnPropertySlot):
283         * runtime/JSMap.cpp:
284         (JSC::JSMap::isIteratorProtocolFastAndNonObservable):
285         * runtime/JSObject.cpp:
286         (JSC::JSObject::calculatedClassName):
287         (JSC::JSObject::setPrototypeWithCycleCheck):
288         (JSC::JSObject::getPrototype):
289         (JSC::JSObject::attemptToInterceptPutByIndexOnHoleForPrototype):
290         (JSC::JSObject::attemptToInterceptPutByIndexOnHole):
291         (JSC::JSObject::anyObjectInChainMayInterceptIndexedAccesses const):
292         (JSC::JSObject::prototypeChainMayInterceptStoreTo):
293         * runtime/JSObject.h:
294         (JSC::JSObject::finishCreation):
295         (JSC::JSObject::getPrototypeDirect const):
296         (JSC::JSObject::getPrototype):
297         * runtime/JSObjectInlines.h:
298         (JSC::JSObject::canPerformFastPutInline):
299         (JSC::JSObject::getPropertySlot):
300         (JSC::JSObject::getNonIndexPropertySlot):
301         * runtime/JSProxy.cpp:
302         (JSC::JSProxy::setTarget):
303         * runtime/JSSet.cpp:
304         (JSC::JSSet::isIteratorProtocolFastAndNonObservable):
305         * runtime/ProgramExecutable.cpp:
306         (JSC::ProgramExecutable::initializeGlobalProperties):
307         * runtime/StructureInlines.h:
308         (JSC::Structure::isValid const):
309
310 2017-10-20  Yusuke Suzuki  <utatane.tea@gmail.com>
311
312         [ARM64] static_cast<int32_t>() in BinaryOpNode::emitBytecode() prevents op_unsigned emission
313         https://bugs.webkit.org/show_bug.cgi?id=178379
314
315         Reviewed by Saam Barati.
316
317         We reuse jsNumber's checking mechanism here to precisely check the generated number is within uint32_t
318         in bytecode compiler. This is reasonable since the NumberNode will generate the exact this JSValue.
319
320         * bytecompiler/NodesCodegen.cpp:
321         (JSC::BinaryOpNode::emitBytecode):
322
323 2017-10-20  Yusuke Suzuki  <utatane.tea@gmail.com>
324
325         [JSC] ScriptFetcher should be notified directly from module pipeline
326         https://bugs.webkit.org/show_bug.cgi?id=178340
327
328         Reviewed by Sam Weinig.
329
330         Previously, we use JSStdFunction to let WebCore inform the module pipeline results.
331         We setup JSStdFunction to the resulted promise of the module pipeline. It is super
332         ad-hoc since JSStdFunction's lambda need extra-careful to make it non-cyclic-referenced.
333         JSStdFunction's lambda can capture variables, but they are not able to be marked by GC.
334
335         But now, we have ScriptFetcher. It is introduced after we implemented the module pipeline
336         notification mechanism by using JSStdFunction. But it is appropriate one to receive notification
337         from the module pipeline by observer style.
338
339         This patch removes the above ad-hoc JSStdFunction use. And now ScriptFetcher receives
340         completion/failure notifications from the module pipeline.
341
342         * builtins/ModuleLoaderPrototype.js:
343         (loadModule):
344         (loadAndEvaluateModule):
345         * runtime/Completion.cpp:
346         (JSC::loadModule):
347         * runtime/Completion.h:
348         * runtime/JSModuleLoader.cpp:
349         (JSC::jsValueToModuleKey):
350         (JSC::JSModuleLoader::notifyCompleted):
351         (JSC::JSModuleLoader::notifyFailed):
352         * runtime/JSModuleLoader.h:
353         * runtime/ModuleLoaderPrototype.cpp:
354         (JSC::moduleLoaderPrototypeNotifyCompleted):
355         (JSC::moduleLoaderPrototypeNotifyFailed):
356         * runtime/ScriptFetcher.h:
357         (JSC::ScriptFetcher::notifyLoadCompleted):
358         (JSC::ScriptFetcher::notifyLoadFailed):
359
360 2017-10-19  JF Bastien  <jfbastien@apple.com>
361
362         WebAssembly: no VM / JS version of everything but Instance
363         https://bugs.webkit.org/show_bug.cgi?id=177473
364
365         Reviewed by Filip Pizlo, Saam Barati.
366
367         This change entails cleaning up and splitting a bunch of code which we had
368         intertwined between C++ classes which represent JS objects, and pure C++
369         implementation objects. This specific change goes most of the way towards
370         allowing JSC's WebAssembly to work without VM / JS, up to but excluding
371         JSWebAssemblyInstance (there's Wasm::Instance, but it's not *the* thing
372         yet). Because of this we still have a few FIXME identifying places that need to
373         change. A follow-up change will go the rest of the way.
374
375         I went about this change in the simplest way possible: grep the
376         JavaScriptCore/wasm directory for "JS[^C_]" as well as "VM" and exclude the /js/
377         sub-directory (which contains the JS implementation of WebAssembly).
378
379         None of this change removes the need for a JIT entitlement to be able to use
380         WebAssembly. We don't have an interpreter, the process therefore still needs to
381         be allowed to JIT to use these pure-C++ APIs.
382
383         Interesting things to note:
384
385           - Remove VM from Plan and associated places. It can just live as a capture in
386             the callback lambda if it's needed.
387           - Wasm::Memory shouldn't require a VM. It was only used to ask the GC to
388             collect. We now instead pass two lambdas at construction time for this
389             purpose: one to notify of memory pressure, and the other to ask for
390             syncrhonous memory reclamation. This allows whoever creates the memory to
391             dictate how to react to both these cases, and for a JS embedding that's to
392             call the GC (async or sync, respectively).
393           - Move grow logic from JSWebAssemblyMemory to Wasm::Memory::grow. Use Expected
394             there, with an enum class for failure types.
395           - Exceeding max on memory growth now returns a range error as per spec. This
396             is a (very minor) breaking change: it used to throw OOM error. Update the
397             corresponding test.
398           - When generating the grow_memory opcode, no need to get the VM. Instead,
399             reach directly for Wasm::Memory and grow it.
400           - JSWebAssemblyMemory::grow can now always throw on failure, because it's only
401             ever called from JS (not from grow_memory as before).
402           - Wasm::Memory now takes a callback for successful growth. This allows JS
403             wrappers to register themselves when growth succeeds without Wasm::Memory
404             knowning anything about JS. It'll also allow creating a list of callbacks
405             for when we add thread support (we'll want to notify many wrappers, all
406             under a lock).
407           - Wasm::Memory is now back to being the source of truth about address / size,
408             used directly by generated code instead of JSWebAssemblyMemory.
409           - Move wasmToJS from the general WasmBinding header to its own header under
410             wasm/js. It's only used by wasm/js/JSWebAssemblyCodeBlock.cpp, and uses VM,
411             and therefore isn't general WebAssembly.
412           - Make Wasm::Context an actual type (just a struct holding a
413             JSWebAssemlyInstance for now) instead of an alias for that. Notably this
414             doesn't add anything to the Context and doesn't change what actually gets
415             passed around in JIT code (fast TLS or registers) because these changes
416             potentially impact performance. The entire purpose of this change is to
417             allow passing Wasm::Context around without having to know about VM. Since VM
418             contains a Wasm::Context the JS embedding is effectively the same, but with
419             this setup a non-JS embedding is much better off.
420           - Move JSWebAssembly into the JS folder.
421           - OMGPlan: use Wasm::CodeBlock directly instead of JSWebAssemblyCodeBlock.
422           - wasm->JS stubs are now on the instance's tail as raw pointers, instead of
423             being on JSWebAssemblyCodeBlock, and are now called wasm->Embedder
424             stubs. The owned reference is still on JSWebAssemblyCodeBlock, and is still
425             called wasm->JS stub. This move means that the embedder must, after creating
426             a Wasm::CodeBlock, somehow create the stubs to call back into the
427             embedder. This removes an indirection in the generated code because
428             the B3 IR generator now reaches into the instance instead of
429             JSWebAssemblyCodeBlock.
430           - Move more CodeBlock things. Compilation completion is now marked by its own
431             atomic<bool> flag instead of a nullptr plan: that required using a lock, and
432             was causing a deadlock in stack-trace.js because before my changes
433             JSWebAssemblyCodeBlock did its own completion checking separately from
434             Wasm::CodeBlock, without getting the lock. Now that everything points to
435             Wasm::CodeBlock and there's no cached completion marker, the lock was being
436             acquired in a sanity-check assertion.
437           - Embedder -> Wasm wrappers are now generated through a function that's passed
438             in at compilation time, instead of being hard-coded as a JS -> Wasm wrapper.
439           - WasmMemory doens't need to know about fault handling thunks. Only the IR
440             generator should know, and should make sure that the exception throwing
441             thunk is generated if any memory is present (note: with signal handling not
442             all of them generate an exception check).
443           - Make exception throwing pluggable: instead of having a hard-coded
444             JS-specific lambda we now have a regular C++ function being called from JIT
445             code when a WebAssembly exception is thrown. This allows any embedder to get
446             called as they wish. For now a process can only have a single of these
447             functions (i.e. only one embedder per process) because the trap handler is a
448             singleton. That can be fixed in in #177475.
449           - Create WasmEmbedder.h where all embedder plugging will live.
450           - Split up JSWebAssemblyTable into Wasm::Table which is
451             refcounted. JSWebAssemblyTable now only contains the JS functions in the
452             table, and Wasm::Table is what's used by the JIT code to lookup where to
453             call and do the instance check (for context switch). Note that this creates
454             an extra allocation for all the instances in Wasm::Table, and in exchange
455             removes an indirection in JIT code because the instance used to be obtained
456             off of the JS function. Also note that it's the embedder than keeps the
457             instances alive, not Wasm::Table (which holds a dumb pointer to the
458             instance), because doing otherwise would cause reference cycles.
459            - Add WasmInstance. It doesn't do much for now, owns globals.
460            - JSWebAssembly instance now doesn't just contain the imported functions as
461              JSObjects, it also has the corresponding import's instance and wasm
462              entrypoint. This triples the space allocated per instance's imported
463              function, but there shouldn't be that many imports. This has two upsides: it
464              creates smaller and faster code, and makes is easier to disassociate
465              embedder-specific things from embedder-neutral things. The small / faster
466              win is in two places: B3 IR generator only needs offsetOfImportFunction for
467              the call opcode (when the called index is an import) to know whether the
468              import is wasm->wasm or wasm->embedder (this isn't known at compile-time
469              because it's dependent on the import object), this is now done by seeing if
470              that import function has an associated target instance (only wasm->wasm
471              does); the other place is wasmBinding which uses offsetOfImportFunction to
472              figure out the wasm->wasm target instance, and then gets
473              WebAssemblyFunction::offsetOfWasmEntrypointLoadLocation to do a tail
474              call. The disassociation comes because the target instance can be
475              Wasm::Instance once we change what the Context is, and
476              WasmEntrypointLoadLocation is already embedder-independent. As a next step I
477              can move this tail allocation from JSWebAssemblyInstance to Wasm::Instance,
478              and leave importFunction in as an opaque pointer which is embedder-specific,
479              and in JS will remain WriteBarrier<JSObject>.
480            - Rename VMEntryFrame to EntryFrame, and in many places pass a pointer to it
481              around instead of VM. This is a first step in allowing entry frames which
482              aren't stored on VM, but which are instead stored in an embedder-specific
483              location. That change won't really affect JS except through code churn, but
484              will allow WebAssembly to use some machinery in a generic manner without
485              having a VM.
486
487         * JavaScriptCore.xcodeproj/project.pbxproj:
488         * Sources.txt:
489         * bytecode/PolymorphicAccess.cpp:
490         (JSC::AccessGenerationState::emitExplicitExceptionHandler):
491         * debugger/Debugger.cpp:
492         (JSC::Debugger::stepOutOfFunction):
493         (JSC::Debugger::returnEvent):
494         (JSC::Debugger::unwindEvent):
495         (JSC::Debugger::didExecuteProgram):
496         * dfg/DFGJITCompiler.cpp:
497         (JSC::DFG::JITCompiler::compileExceptionHandlers):
498         * dfg/DFGOSREntry.cpp:
499         (JSC::DFG::prepareOSREntry):
500         * dfg/DFGOSRExit.cpp:
501         (JSC::DFG::OSRExit::compileOSRExit):
502         (JSC::DFG::OSRExit::compileExit):
503         * dfg/DFGThunks.cpp:
504         (JSC::DFG::osrEntryThunkGenerator):
505         * ftl/FTLCompile.cpp:
506         (JSC::FTL::compile):
507         * ftl/FTLLink.cpp:
508         (JSC::FTL::link):
509         * ftl/FTLLowerDFGToB3.cpp:
510         (JSC::FTL::DFG::LowerDFGToB3::lower):
511         * ftl/FTLOSRExitCompiler.cpp:
512         (JSC::FTL::compileStub):
513         * interpreter/CallFrame.cpp:
514         (JSC::CallFrame::wasmAwareLexicalGlobalObject):
515         (JSC::CallFrame::callerFrame):
516         (JSC::CallFrame::unsafeCallerFrame):
517         * interpreter/CallFrame.h:
518         (JSC::ExecState::callerFrame const):
519         (JSC::ExecState::callerFrameOrEntryFrame const):
520         (JSC::ExecState::unsafeCallerFrameOrEntryFrame const):
521         * interpreter/FrameTracers.h:
522         (JSC::NativeCallFrameTracer::NativeCallFrameTracer):
523         (JSC::NativeCallFrameTracerWithRestore::NativeCallFrameTracerWithRestore):
524         (JSC::NativeCallFrameTracerWithRestore::~NativeCallFrameTracerWithRestore):
525         * interpreter/Interpreter.cpp:
526         (JSC::UnwindFunctor::operator() const):
527         (JSC::UnwindFunctor::copyCalleeSavesToEntryFrameCalleeSavesBuffer const):
528         (JSC::Interpreter::unwind):
529         * interpreter/StackVisitor.cpp:
530         (JSC::StackVisitor::StackVisitor):
531         (JSC::StackVisitor::gotoNextFrame):
532         (JSC::StackVisitor::readNonInlinedFrame):
533         (JSC::StackVisitor::Frame::dump const):
534         * interpreter/StackVisitor.h:
535         (JSC::StackVisitor::Frame::callerIsEntryFrame const):
536         * interpreter/VMEntryRecord.h:
537         (JSC::VMEntryRecord::prevTopEntryFrame):
538         (JSC::VMEntryRecord::unsafePrevTopEntryFrame):
539         (JSC::EntryFrame::vmEntryRecordOffset):
540         * jit/AssemblyHelpers.cpp:
541         (JSC::AssemblyHelpers::restoreCalleeSavesFromEntryFrameCalleeSavesBuffer):
542         (JSC::AssemblyHelpers::loadWasmContextInstance):
543         (JSC::AssemblyHelpers::storeWasmContextInstance):
544         (JSC::AssemblyHelpers::loadWasmContextInstanceNeedsMacroScratchRegister):
545         (JSC::AssemblyHelpers::storeWasmContextInstanceNeedsMacroScratchRegister):
546         (JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBufferImpl):
547         * jit/AssemblyHelpers.h:
548         (JSC::AssemblyHelpers::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
549         (JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBuffer):
550         (JSC::AssemblyHelpers::copyCalleeSavesFromFrameOrRegisterToEntryFrameCalleeSavesBuffer):
551         * jit/JIT.cpp:
552         (JSC::JIT::emitEnterOptimizationCheck):
553         (JSC::JIT::privateCompileExceptionHandlers):
554         * jit/JITExceptions.cpp:
555         (JSC::genericUnwind):
556         * jit/JITOpcodes.cpp:
557         (JSC::JIT::emit_op_throw):
558         (JSC::JIT::emit_op_catch):
559         (JSC::JIT::emitSlow_op_loop_hint):
560         * jit/JITOpcodes32_64.cpp:
561         (JSC::JIT::emit_op_throw):
562         (JSC::JIT::emit_op_catch):
563         * jit/JITOperations.cpp:
564         * jit/ThunkGenerators.cpp:
565         (JSC::throwExceptionFromCallSlowPathGenerator):
566         (JSC::nativeForGenerator):
567         * jsc.cpp:
568         (functionDumpCallFrame):
569         * llint/LLIntSlowPaths.cpp:
570         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
571         * llint/LLIntThunks.cpp:
572         (JSC::vmEntryRecord):
573         * llint/LowLevelInterpreter.asm:
574         * llint/LowLevelInterpreter32_64.asm:
575         * llint/LowLevelInterpreter64.asm:
576         * runtime/Options.cpp:
577         (JSC::recomputeDependentOptions):
578         * runtime/Options.h:
579         * runtime/SamplingProfiler.cpp:
580         (JSC::FrameWalker::FrameWalker):
581         (JSC::FrameWalker::advanceToParentFrame):
582         (JSC::SamplingProfiler::processUnverifiedStackTraces):
583         * runtime/ThrowScope.cpp:
584         (JSC::ThrowScope::~ThrowScope):
585         * runtime/VM.cpp:
586         (JSC::VM::VM):
587         (JSC::VM::~VM):
588         * runtime/VM.h:
589         (JSC::VM::topEntryFrameOffset):
590         * runtime/VMTraps.cpp:
591         (JSC::isSaneFrame):
592         (JSC::VMTraps::tryInstallTrapBreakpoints):
593         (JSC::VMTraps::invalidateCodeBlocksOnStack):
594         * wasm/WasmB3IRGenerator.cpp:
595         (JSC::Wasm::B3IRGenerator::restoreWasmContextInstance):
596         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
597         (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
598         (JSC::Wasm::B3IRGenerator::addGrowMemory):
599         (JSC::Wasm::B3IRGenerator::addCurrentMemory):
600         (JSC::Wasm::B3IRGenerator::addCall):
601         (JSC::Wasm::B3IRGenerator::addCallIndirect):
602         (JSC::Wasm::parseAndCompile):
603         * wasm/WasmB3IRGenerator.h:
604         * wasm/WasmBBQPlan.cpp:
605         (JSC::Wasm::BBQPlan::BBQPlan):
606         (JSC::Wasm::BBQPlan::compileFunctions):
607         (JSC::Wasm::BBQPlan::complete):
608         * wasm/WasmBBQPlan.h:
609         * wasm/WasmBBQPlanInlines.h:
610         (JSC::Wasm::BBQPlan::initializeCallees):
611         * wasm/WasmBinding.cpp:
612         (JSC::Wasm::wasmToWasm):
613         * wasm/WasmBinding.h:
614         * wasm/WasmCodeBlock.cpp:
615         (JSC::Wasm::CodeBlock::create):
616         (JSC::Wasm::CodeBlock::CodeBlock):
617         (JSC::Wasm::CodeBlock::compileAsync):
618         (JSC::Wasm::CodeBlock::setCompilationFinished):
619         * wasm/WasmCodeBlock.h:
620         (JSC::Wasm::CodeBlock::offsetOfImportStubs):
621         (JSC::Wasm::CodeBlock::allocationSize):
622         (JSC::Wasm::CodeBlock::importWasmToEmbedderStub):
623         (JSC::Wasm::CodeBlock::offsetOfImportWasmToEmbedderStub):
624         (JSC::Wasm::CodeBlock::wasmToJSCallStubForImport):
625         (JSC::Wasm::CodeBlock::compilationFinished):
626         (JSC::Wasm::CodeBlock::jsEntrypointCalleeFromFunctionIndexSpace):
627         (JSC::Wasm::CodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace):
628         * wasm/WasmContext.cpp:
629         (JSC::Wasm::Context::useFastTLS):
630         (JSC::Wasm::Context::load const):
631         (JSC::Wasm::Context::store):
632         * wasm/WasmContext.h:
633         * wasm/WasmEmbedder.h: Copied from Source/JavaScriptCore/wasm/WasmContext.h.
634         * wasm/WasmFaultSignalHandler.cpp:
635         * wasm/WasmFaultSignalHandler.h:
636         * wasm/WasmFormat.h:
637         * wasm/WasmInstance.cpp: Copied from Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h.
638         (JSC::Wasm::Instance::Instance):
639         (JSC::Wasm::Instance::~Instance):
640         (JSC::Wasm::Instance::extraMemoryAllocated const):
641         * wasm/WasmInstance.h: Added.
642         (JSC::Wasm::Instance::create):
643         (JSC::Wasm::Instance::finalizeCreation):
644         (JSC::Wasm::Instance::module):
645         (JSC::Wasm::Instance::codeBlock):
646         (JSC::Wasm::Instance::memory):
647         (JSC::Wasm::Instance::table):
648         (JSC::Wasm::Instance::loadI32Global const):
649         (JSC::Wasm::Instance::loadI64Global const):
650         (JSC::Wasm::Instance::loadF32Global const):
651         (JSC::Wasm::Instance::loadF64Global const):
652         (JSC::Wasm::Instance::setGlobal):
653         (JSC::Wasm::Instance::offsetOfCachedStackLimit):
654         (JSC::Wasm::Instance::cachedStackLimit const):
655         (JSC::Wasm::Instance::setCachedStackLimit):
656         * wasm/WasmMemory.cpp:
657         (JSC::Wasm::Memory::Memory):
658         (JSC::Wasm::Memory::create):
659         (JSC::Wasm::Memory::~Memory):
660         (JSC::Wasm::Memory::grow):
661         * wasm/WasmMemory.h:
662         (JSC::Wasm::Memory::offsetOfMemory):
663         (JSC::Wasm::Memory::offsetOfSize):
664         * wasm/WasmMemoryInformation.cpp:
665         (JSC::Wasm::PinnedRegisterInfo::get):
666         (JSC::Wasm::PinnedRegisterInfo::PinnedRegisterInfo):
667         * wasm/WasmMemoryInformation.h:
668         (JSC::Wasm::PinnedRegisterInfo::toSave const):
669         * wasm/WasmMemoryMode.cpp: Copied from Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h.
670         (JSC::Wasm::makeString):
671         * wasm/WasmMemoryMode.h: Copied from Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h.
672         * wasm/WasmModule.cpp:
673         (JSC::Wasm::makeValidationCallback):
674         (JSC::Wasm::Module::validateSync):
675         (JSC::Wasm::Module::validateAsync):
676         (JSC::Wasm::Module::getOrCreateCodeBlock):
677         (JSC::Wasm::Module::compileSync):
678         (JSC::Wasm::Module::compileAsync):
679         * wasm/WasmModule.h:
680         * wasm/WasmModuleParser.cpp:
681         (JSC::Wasm::ModuleParser::parseTableHelper):
682         * wasm/WasmOMGPlan.cpp:
683         (JSC::Wasm::OMGPlan::OMGPlan):
684         (JSC::Wasm::OMGPlan::runForIndex):
685         * wasm/WasmOMGPlan.h:
686         * wasm/WasmPageCount.h:
687         (JSC::Wasm::PageCount::isValid const):
688         * wasm/WasmPlan.cpp:
689         (JSC::Wasm::Plan::Plan):
690         (JSC::Wasm::Plan::runCompletionTasks):
691         (JSC::Wasm::Plan::addCompletionTask):
692         (JSC::Wasm::Plan::tryRemoveContextAndCancelIfLast):
693         * wasm/WasmPlan.h:
694         (JSC::Wasm::Plan::dontFinalize):
695         * wasm/WasmSignature.cpp:
696         * wasm/WasmSignature.h:
697         * wasm/WasmTable.cpp: Added.
698         (JSC::Wasm::Table::create):
699         (JSC::Wasm::Table::~Table):
700         (JSC::Wasm::Table::Table):
701         (JSC::Wasm::Table::grow):
702         (JSC::Wasm::Table::clearFunction):
703         (JSC::Wasm::Table::setFunction):
704         * wasm/WasmTable.h: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyTable.h.
705         (JSC::Wasm::Table::maximum const):
706         (JSC::Wasm::Table::size const):
707         (JSC::Wasm::Table::offsetOfSize):
708         (JSC::Wasm::Table::offsetOfFunctions):
709         (JSC::Wasm::Table::offsetOfInstances):
710         (JSC::Wasm::Table::isValidSize):
711         * wasm/WasmThunks.cpp:
712         (JSC::Wasm::throwExceptionFromWasmThunkGenerator):
713         (JSC::Wasm::triggerOMGTierUpThunkGenerator):
714         (JSC::Wasm::Thunks::setThrowWasmException):
715         (JSC::Wasm::Thunks::throwWasmException):
716         * wasm/WasmThunks.h:
717         * wasm/WasmWorklist.cpp:
718         (JSC::Wasm::Worklist::stopAllPlansForContext):
719         * wasm/WasmWorklist.h:
720         * wasm/js/JSToWasm.cpp: Added.
721         (JSC::Wasm::createJSToWasmWrapper):
722         * wasm/js/JSToWasm.h: Copied from Source/JavaScriptCore/wasm/WasmBinding.h.
723         * wasm/js/JSWebAssembly.cpp: Renamed from Source/JavaScriptCore/wasm/JSWebAssembly.cpp.
724         * wasm/js/JSWebAssembly.h: Renamed from Source/JavaScriptCore/wasm/JSWebAssembly.h.
725         * wasm/js/JSWebAssemblyCodeBlock.cpp:
726         (JSC::JSWebAssemblyCodeBlock::create):
727         (JSC::JSWebAssemblyCodeBlock::JSWebAssemblyCodeBlock):
728         * wasm/js/JSWebAssemblyCodeBlock.h:
729         * wasm/js/JSWebAssemblyInstance.cpp:
730         (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
731         (JSC::JSWebAssemblyInstance::finishCreation):
732         (JSC::JSWebAssemblyInstance::visitChildren):
733         (JSC::JSWebAssemblyInstance::finalizeCreation):
734         (JSC::JSWebAssemblyInstance::create):
735         * wasm/js/JSWebAssemblyInstance.h:
736         (JSC::JSWebAssemblyInstance::instance):
737         (JSC::JSWebAssemblyInstance::context const):
738         (JSC::JSWebAssemblyInstance::table):
739         (JSC::JSWebAssemblyInstance::webAssemblyToJSCallee):
740         (JSC::JSWebAssemblyInstance::setMemory):
741         (JSC::JSWebAssemblyInstance::offsetOfTail):
742         (JSC::JSWebAssemblyInstance::importFunctionInfo):
743         (JSC::JSWebAssemblyInstance::offsetOfTargetInstance):
744         (JSC::JSWebAssemblyInstance::offsetOfWasmEntrypoint):
745         (JSC::JSWebAssemblyInstance::offsetOfImportFunction):
746         (JSC::JSWebAssemblyInstance::importFunction):
747         (JSC::JSWebAssemblyInstance::internalMemory):
748         (JSC::JSWebAssemblyInstance::wasmCodeBlock const):
749         (JSC::JSWebAssemblyInstance::offsetOfWasmTable):
750         (JSC::JSWebAssemblyInstance::offsetOfCallee):
751         (JSC::JSWebAssemblyInstance::offsetOfGlobals):
752         (JSC::JSWebAssemblyInstance::offsetOfWasmCodeBlock):
753         (JSC::JSWebAssemblyInstance::offsetOfWasmMemory):
754         (JSC::JSWebAssemblyInstance::cachedStackLimit const):
755         (JSC::JSWebAssemblyInstance::setCachedStackLimit):
756         (JSC::JSWebAssemblyInstance::wasmMemory):
757         (JSC::JSWebAssemblyInstance::wasmModule):
758         (JSC::JSWebAssemblyInstance::allocationSize):
759         (JSC::JSWebAssemblyInstance::module const):
760         * wasm/js/JSWebAssemblyMemory.cpp:
761         (JSC::JSWebAssemblyMemory::create):
762         (JSC::JSWebAssemblyMemory::adopt):
763         (JSC::JSWebAssemblyMemory::JSWebAssemblyMemory):
764         (JSC::JSWebAssemblyMemory::grow):
765         (JSC::JSWebAssemblyMemory::growSuccessCallback):
766         * wasm/js/JSWebAssemblyMemory.h:
767         * wasm/js/JSWebAssemblyModule.cpp:
768         (JSC::JSWebAssemblyModule::moduleInformation const):
769         (JSC::JSWebAssemblyModule::exportSymbolTable const):
770         (JSC::JSWebAssemblyModule::signatureIndexFromFunctionIndexSpace const):
771         (JSC::JSWebAssemblyModule::callee const):
772         (JSC::JSWebAssemblyModule::codeBlock):
773         (JSC::JSWebAssemblyModule::module):
774         * wasm/js/JSWebAssemblyModule.h:
775         * wasm/js/JSWebAssemblyTable.cpp:
776         (JSC::JSWebAssemblyTable::create):
777         (JSC::JSWebAssemblyTable::JSWebAssemblyTable):
778         (JSC::JSWebAssemblyTable::visitChildren):
779         (JSC::JSWebAssemblyTable::grow):
780         (JSC::JSWebAssemblyTable::getFunction):
781         (JSC::JSWebAssemblyTable::clearFunction):
782         (JSC::JSWebAssemblyTable::setFunction):
783         * wasm/js/JSWebAssemblyTable.h:
784         (JSC::JSWebAssemblyTable::isValidSize):
785         (JSC::JSWebAssemblyTable::maximum const):
786         (JSC::JSWebAssemblyTable::size const):
787         (JSC::JSWebAssemblyTable::table):
788         * wasm/js/WasmToJS.cpp: Copied from Source/JavaScriptCore/wasm/WasmBinding.cpp.
789         (JSC::Wasm::materializeImportJSCell):
790         (JSC::Wasm::wasmToJS):
791         (JSC::Wasm::wasmToJSException):
792         * wasm/js/WasmToJS.h: Copied from Source/JavaScriptCore/wasm/WasmBinding.h.
793         * wasm/js/WebAssemblyFunction.cpp:
794         (JSC::callWebAssemblyFunction):
795         * wasm/js/WebAssemblyInstanceConstructor.cpp:
796         (JSC::constructJSWebAssemblyInstance):
797         * wasm/js/WebAssemblyMemoryConstructor.cpp:
798         (JSC::constructJSWebAssemblyMemory):
799         * wasm/js/WebAssemblyMemoryPrototype.cpp:
800         (JSC::webAssemblyMemoryProtoFuncGrow):
801         * wasm/js/WebAssemblyModuleConstructor.cpp:
802         (JSC::constructJSWebAssemblyModule):
803         (JSC::WebAssemblyModuleConstructor::createModule):
804         * wasm/js/WebAssemblyModuleConstructor.h:
805         * wasm/js/WebAssemblyModuleRecord.cpp:
806         (JSC::WebAssemblyModuleRecord::link):
807         (JSC::WebAssemblyModuleRecord::evaluate):
808         * wasm/js/WebAssemblyPrototype.cpp:
809         (JSC::webAssemblyCompileFunc):
810         (JSC::instantiate):
811         (JSC::compileAndInstantiate):
812         (JSC::webAssemblyValidateFunc):
813         * wasm/js/WebAssemblyTableConstructor.cpp:
814         (JSC::constructJSWebAssemblyTable):
815         * wasm/js/WebAssemblyWrapperFunction.cpp:
816         (JSC::WebAssemblyWrapperFunction::create):
817
818 2017-10-19  Mark Lam  <mark.lam@apple.com>
819
820         Stringifier::appendStringifiedValue() is missing an exception check.
821         https://bugs.webkit.org/show_bug.cgi?id=178386
822         <rdar://problem/35027610>
823
824         Reviewed by Saam Barati.
825
826         * runtime/JSONObject.cpp:
827         (JSC::Stringifier::appendStringifiedValue):
828
829 2017-10-19  Saam Barati  <sbarati@apple.com>
830
831         REGRESSION(r223691): DFGByteCodeParser.cpp:1483:83: warning: comparison is always false due to limited range of data type [-Wtype-limits]
832         https://bugs.webkit.org/show_bug.cgi?id=178543
833
834         Reviewed by Filip Pizlo.
835
836         * dfg/DFGByteCodeParser.cpp:
837         (JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
838
839 2017-10-19  Saam Barati  <sbarati@apple.com>
840
841         re-inline ObjectAllocationProfile::initializeProfile
842         https://bugs.webkit.org/show_bug.cgi?id=178532
843
844         Rubber stamped by Michael Saboff.
845
846         I un-inlined this function when implementing poly proto.
847         This patch re-inlines it. In my testing, it looks like it
848         might be a 0.5% speedometer progression to inline it.
849
850         * JavaScriptCore.xcodeproj/project.pbxproj:
851         * Sources.txt:
852         * bytecode/CodeBlock.cpp:
853         * bytecode/ObjectAllocationProfile.cpp: Removed.
854         * bytecode/ObjectAllocationProfileInlines.h: Copied from Source/JavaScriptCore/bytecode/ObjectAllocationProfile.cpp.
855         (JSC::ObjectAllocationProfile::initializeProfile):
856         (JSC::ObjectAllocationProfile::possibleDefaultPropertyCount):
857         * runtime/FunctionRareData.cpp:
858
859 2017-10-19  Michael Saboff  <msaboff@apple.com>
860
861         Test262: RegExp/property-escapes/generated/Emoji_Component.js fails with current RegExp Unicode Properties implementation
862         https://bugs.webkit.org/show_bug.cgi?id=178521
863
864         Reviewed by JF Bastien.
865
866         * ucd/emoji-data.txt: Replaced with the Unicode Emoji 5.0 version of the file as that is the most recent
867         standard version.  The prior version was the draft 6.0 version.
868
869 2017-10-19  Saam Barati  <sbarati@apple.com>
870
871         We should hard code the poly proto offset
872         https://bugs.webkit.org/show_bug.cgi?id=178531
873
874         Reviewed by Filip Pizlo.
875
876         This patch embraces that the poly proto offset is always zero. It's already
877         the case that we would always get the inline offset zero for poly proto just
878         by construction. This just hardcodes this assumption throughout the codebase.
879         This appears to be a 1% speedometer progression in my testing.
880         
881         The downside of this patch is that it may require changing how we do
882         things when we implement poly proto when inheriting from builtin
883         types. I think we can face this problem when we decide to implement
884         that.
885
886         * bytecode/AccessCase.cpp:
887         (JSC::AccessCase::generateWithGuard):
888         * dfg/DFGOperations.cpp:
889         * dfg/DFGSpeculativeJIT.cpp:
890         (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
891         (JSC::DFG::SpeculativeJIT::compileGetPrototypeOf):
892         * ftl/FTLLowerDFGToB3.cpp:
893         (JSC::FTL::DFG::LowerDFGToB3::compileGetPrototypeOf):
894         (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
895         * jit/JITOpcodes.cpp:
896         (JSC::JIT::emit_op_instanceof):
897         * jit/JITOpcodes32_64.cpp:
898         (JSC::JIT::emit_op_instanceof):
899         * runtime/CommonSlowPaths.cpp:
900         (JSC::SLOW_PATH_DECL):
901         * runtime/JSObject.cpp:
902         (JSC::JSObject::setPrototypeDirect):
903         * runtime/JSObject.h:
904         (JSC::JSObject::locationForOffset const):
905         (JSC::JSObject::locationForOffset):
906         (JSC::JSObject::getDirect const):
907         * runtime/PropertyOffset.h:
908         * runtime/Structure.cpp:
909         (JSC::Structure::create):
910         (JSC::Structure::dump const):
911         * runtime/Structure.h:
912         * runtime/StructureInlines.h:
913         (JSC::Structure::storedPrototype const):
914         (JSC::Structure::storedPrototypeObject const):
915
916 2017-10-19  Saam Barati  <sbarati@apple.com>
917
918         Turn various poly proto RELEASE_ASSERTs into ASSERTs because they're on the hot path in speedometer
919         https://bugs.webkit.org/show_bug.cgi?id=178529
920
921         Reviewed by Mark Lam.
922
923         * runtime/Structure.h:
924         * runtime/StructureInlines.h:
925         (JSC::Structure::storedPrototypeObject const):
926         (JSC::Structure::storedPrototypeStructure const):
927         (JSC::Structure::storedPrototype const):
928         (JSC::Structure::prototypeForLookup const):
929         (JSC::Structure::prototypeChain const):
930
931 2017-10-19  Saam Barati  <sbarati@apple.com>
932
933         Turn poly proto back on by default and remove the option
934         https://bugs.webkit.org/show_bug.cgi?id=178525
935
936         Reviewed by Mark Lam.
937
938         I added this option because I thought it'd speed speedometer up because the
939         original poly proto patch slowed speedometer down. It turns out that
940         allocating poly proto objects is not what slows speedometer down. It's
941         other code I added in the runtime that needs to be poly proto aware. I'll
942         be addressing these in follow up patches.
943
944         * runtime/Options.h:
945         * runtime/StructureInlines.h:
946         (JSC::Structure::shouldConvertToPolyProto):
947
948 2017-10-19  Robin Morisset  <rmorisset@apple.com>
949
950         Turn recursive tail calls into loops
951         https://bugs.webkit.org/show_bug.cgi?id=176601
952
953         Reviewed by Saam Barati.
954
955         We want to turn recursive tail calls into loops early in the pipeline, so that the loops can then be optimized.
956         One difficulty is that we need to split the entry block of the function we are jumping to in order to have somewhere to jump to.
957         Worse: it is not necessarily the first block of the codeBlock, because of inlining! So we must do the splitting in the DFGByteCodeParser, at the same time as inlining.
958         We do this part through modifying the computation of the jump targets.
959         Importantly, we only do this splitting for functions that have tail calls.
960         It is the only case where the optimisation is sound, and doing the splitting unconditionnaly destroys performance on Octane/raytrace.
961
962         We must then do the actual transformation also in DFGByteCodeParser, to avoid code motion moving code out of the body of what will become a loop.
963         The transformation is entirely contained in handleRecursiveTailCall, which is hooked to the inlining machinery.
964
965         * bytecode/CodeBlock.h:
966         (JSC::CodeBlock::hasTailCalls const):
967         * bytecode/PreciseJumpTargets.cpp:
968         (JSC::getJumpTargetsForBytecodeOffset):
969         (JSC::computePreciseJumpTargetsInternal):
970         * bytecode/UnlinkedCodeBlock.cpp:
971         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
972         * bytecode/UnlinkedCodeBlock.h:
973         (JSC::UnlinkedCodeBlock::hasTailCalls const):
974         (JSC::UnlinkedCodeBlock::setHasTailCalls):
975         * bytecompiler/BytecodeGenerator.cpp:
976         (JSC::BytecodeGenerator::emitEnter):
977         (JSC::BytecodeGenerator::emitCallInTailPosition):
978         * dfg/DFGByteCodeParser.cpp:
979         (JSC::DFG::ByteCodeParser::allocateTargetableBlock):
980         (JSC::DFG::ByteCodeParser::makeBlockTargetable):
981         (JSC::DFG::ByteCodeParser::handleCall):
982         (JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
983         (JSC::DFG::ByteCodeParser::parseBlock):
984         (JSC::DFG::ByteCodeParser::parse):
985
986 2017-10-18  Mark Lam  <mark.lam@apple.com>
987
988         RegExpObject::defineOwnProperty() does not need to compare values if no descriptor value is specified.
989         https://bugs.webkit.org/show_bug.cgi?id=177600
990         <rdar://problem/34710985>
991
992         Reviewed by Saam Barati.
993
994         According to http://www.ecma-international.org/ecma-262/8.0/#sec-validateandapplypropertydescriptor,
995         section 9.1.6.3-7.a.ii, we should only check if the value is the same if the
996         descriptor value is present.
997
998         * runtime/RegExpObject.cpp:
999         (JSC::RegExpObject::defineOwnProperty):
1000
1001 2017-10-18  Keith Miller  <keith_miller@apple.com>
1002
1003         Setup WebCore build to start using unified sources.
1004         https://bugs.webkit.org/show_bug.cgi?id=178362
1005
1006         Reviewed by Tim Horton.
1007
1008         Change comments in source list files. Also, pass explicit names for build files.
1009
1010         * CMakeLists.txt:
1011         * PlatformGTK.cmake:
1012         * PlatformMac.cmake:
1013         * Sources.txt:
1014         * SourcesGTK.txt:
1015         * SourcesMac.txt:
1016
1017 2017-10-18  Commit Queue  <commit-queue@webkit.org>
1018
1019         Unreviewed, rolling out r223321.
1020         https://bugs.webkit.org/show_bug.cgi?id=178476
1021
1022         This protocol change broke some internal builds (Requested by
1023         brrian__ on #webkit).
1024
1025         Reverted changeset:
1026
1027         "Web Inspector: provide a way to enable/disable event
1028         listeners"
1029         https://bugs.webkit.org/show_bug.cgi?id=177451
1030         https://trac.webkit.org/changeset/223321
1031
1032 2017-10-18  Mark Lam  <mark.lam@apple.com>
1033
1034         The compiler should always register a structure when it adds its transitionWatchPointSet.
1035         https://bugs.webkit.org/show_bug.cgi?id=178420
1036         <rdar://problem/34814024>
1037
1038         Reviewed by Saam Barati and Filip Pizlo.
1039
1040         Instead of invoking addLazily() to add a structure's transitionWatchpointSet, we
1041         now invoke Graph::registerAndWatchStructureTransition() on the structure.
1042         registerAndWatchStructureTransition() both registers the structure and add its
1043         transitionWatchpointSet to the plan desired watchpoints.
1044
1045         Graph::registerAndWatchStructureTransition() is based on Graph::registerStructure()
1046         except registerAndWatchStructureTransition() adds the structure's
1047         transitionWatchpointSet unconditionally.
1048
1049         * dfg/DFGArgumentsEliminationPhase.cpp:
1050         * dfg/DFGArrayMode.cpp:
1051         (JSC::DFG::ArrayMode::refine const):
1052         * dfg/DFGByteCodeParser.cpp:
1053         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
1054         * dfg/DFGFixupPhase.cpp:
1055         (JSC::DFG::FixupPhase::fixupNode):
1056
1057         * dfg/DFGGraph.cpp:
1058         (JSC::DFG::Graph::registerAndWatchStructureTransition):
1059         * dfg/DFGGraph.h:
1060
1061         * dfg/DFGSpeculativeJIT.cpp:
1062         (JSC::DFG::SpeculativeJIT::compileGetByValOnString):
1063         - The second set of addLazily()s is redundant.  This set is executed only when
1064           prototypeChainIsSane is true, and prototypeChainIsSane can only be true if and
1065           only if we've executed the if statement above it.  That preceding if statement
1066           already registerAndWatchStructureTransition() the same 2 structures.  Hence,
1067           this second set can be deleted.
1068
1069         * dfg/DFGWatchpointCollectionPhase.cpp:
1070         (JSC::DFG::WatchpointCollectionPhase::addLazily):
1071         - Deleted an unused function.
1072
1073         * ftl/FTLLowerDFGToB3.cpp:
1074         (JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
1075
1076 2017-10-18  Yusuke Suzuki  <utatane.tea@gmail.com>
1077
1078         [JSC] Remove unused private name structure
1079         https://bugs.webkit.org/show_bug.cgi?id=178436
1080
1081         Reviewed by Sam Weinig.
1082
1083         It is no longer used. This patch just removes it.
1084
1085         * runtime/JSGlobalObject.h:
1086         (JSC::JSGlobalObject::numberObjectStructure const):
1087         (JSC::JSGlobalObject::privateNameStructure const): Deleted.
1088
1089 2017-10-18  Ryosuke Niwa  <rniwa@webkit.org>
1090
1091         Fix macOS and iOS builds after r223594.
1092
1093         * JavaScriptCore.xcodeproj/project.pbxproj:
1094
1095 2017-10-18  Yusuke Suzuki  <utatane.tea@gmail.com>
1096
1097         [JSC] __proto__ getter should be fast
1098         https://bugs.webkit.org/show_bug.cgi?id=178067
1099
1100         Reviewed by Saam Barati.
1101
1102         In our ES6 class implementation, we access __proto__ field to retrieve super constructor.
1103         Currently, it is handled as an usual getter call to a generic function. And DFG just emits
1104         Call node for this. It is inefficient since typically we know the `prototype` of the given
1105         object when accessing `object.__proto__` since we emit CheckStructure for this `object`.
1106         If Structure has mono proto, we can immediately fold it to constant value. If it is poly proto,
1107         we can still change this to efficient access to poly proto slot.
1108
1109         This patch implements GetPrototypeOf DFG node. This node efficiently accesses to prototype of
1110         the given object. And in AI and ByteCodeParser phase, we attempt to fold it to constant.
1111         ByteCodeParser's folding is a bit important since we have `callee.__proto__` code to get super
1112         constructor. If we can change this to constant, we can reify CallLinkInfo with this constant.
1113         This paves the way to optimizing ArrayConstructor super calls[1], which is particularly important
1114         for ARES-6 ML.
1115
1116         And we also optimize Reflect.getPrototypeOf and Object.getPrototypeOf with this GetPrototypeOf node.
1117
1118         Currently, __proto__ access for poly proto object is not handled well in IC. But we add code handling
1119         poly proto in GetPrototypeOf since Reflect.getPrototypeOf and Object.getPrototypeOf can use it.
1120         Once IC starts handling poly proto & intrinsic getter well, this code will be used for that too.
1121
1122         This patch improves SixSpeed super.es6 by 3.42x.
1123
1124                                  baseline                  patched
1125
1126         super.es6           123.6666+-3.9917     ^     36.1684+-1.0351        ^ definitely 3.4192x faster
1127
1128         [1]: https://bugs.webkit.org/show_bug.cgi?id=178064
1129
1130         * dfg/DFGAbstractInterpreterInlines.h:
1131         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1132         * dfg/DFGByteCodeParser.cpp:
1133         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
1134         (JSC::DFG::ByteCodeParser::handleIntrinsicGetter):
1135         (JSC::DFG::ByteCodeParser::handleGetById):
1136         * dfg/DFGClobberize.h:
1137         (JSC::DFG::clobberize):
1138         * dfg/DFGDoesGC.cpp:
1139         (JSC::DFG::doesGC):
1140         * dfg/DFGFixupPhase.cpp:
1141         (JSC::DFG::FixupPhase::fixupNode):
1142         (JSC::DFG::FixupPhase::fixupGetPrototypeOf):
1143         * dfg/DFGHeapLocation.cpp:
1144         (WTF::printInternal):
1145         * dfg/DFGHeapLocation.h:
1146         * dfg/DFGNode.h:
1147         (JSC::DFG::Node::hasHeapPrediction):
1148         (JSC::DFG::Node::shouldSpeculateFunction):
1149         * dfg/DFGNodeType.h:
1150         * dfg/DFGOperations.cpp:
1151         * dfg/DFGOperations.h:
1152         * dfg/DFGPredictionPropagationPhase.cpp:
1153         * dfg/DFGSafeToExecute.h:
1154         (JSC::DFG::safeToExecute):
1155         * dfg/DFGSpeculativeJIT.cpp:
1156         (JSC::DFG::SpeculativeJIT::speculateFunction):
1157         (JSC::DFG::SpeculativeJIT::speculateFinalObject):
1158         (JSC::DFG::SpeculativeJIT::compileGetPrototypeOf):
1159         * dfg/DFGSpeculativeJIT.h:
1160         (JSC::DFG::SpeculativeJIT::callOperation):
1161         * dfg/DFGSpeculativeJIT32_64.cpp:
1162         (JSC::DFG::SpeculativeJIT::compile):
1163         * dfg/DFGSpeculativeJIT64.cpp:
1164         (JSC::DFG::SpeculativeJIT::compile):
1165         * ftl/FTLCapabilities.cpp:
1166         (JSC::FTL::canCompile):
1167         * ftl/FTLLowerDFGToB3.cpp:
1168         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1169         (JSC::FTL::DFG::LowerDFGToB3::compileGetPrototypeOf):
1170         (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
1171         * jit/IntrinsicEmitter.cpp:
1172         (JSC::IntrinsicGetterAccessCase::canEmitIntrinsicGetter):
1173         (JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter):
1174         * jit/JITOperations.h:
1175         * runtime/Intrinsic.cpp:
1176         (JSC::intrinsicName):
1177         * runtime/Intrinsic.h:
1178         * runtime/JSGlobalObject.cpp:
1179         (JSC::JSGlobalObject::init):
1180         * runtime/JSGlobalObject.h:
1181         (JSC::JSGlobalObject::booleanPrototype const):
1182         (JSC::JSGlobalObject::numberPrototype const):
1183         (JSC::JSGlobalObject::booleanObjectStructure const):
1184         * runtime/JSGlobalObjectFunctions.cpp:
1185         (JSC::globalFuncProtoGetter):
1186         * runtime/JSGlobalObjectFunctions.h:
1187         * runtime/ObjectConstructor.cpp:
1188         * runtime/ReflectObject.cpp:
1189
1190 2017-10-17  Ryan Haddad  <ryanhaddad@apple.com>
1191
1192         Unreviewed, rolling out r223523.
1193
1194         A test for this change is failing on debug JSC bots.
1195
1196         Reverted changeset:
1197
1198         "[JSC] __proto__ getter should be fast"
1199         https://bugs.webkit.org/show_bug.cgi?id=178067
1200         https://trac.webkit.org/changeset/223523
1201
1202 2017-10-17  Youenn Fablet  <youenn@apple.com>
1203
1204         Add preliminary support for fetch event
1205         https://bugs.webkit.org/show_bug.cgi?id=178171
1206
1207         Reviewed by Chris Dumez.
1208
1209         Adding events
1210
1211         * runtime/JSPromise.h:
1212
1213 2017-10-10  Yusuke Suzuki  <utatane.tea@gmail.com>
1214
1215         [JSC] __proto__ getter should be fast
1216         https://bugs.webkit.org/show_bug.cgi?id=178067
1217
1218         Reviewed by Saam Barati.
1219
1220         In our ES6 class implementation, we access __proto__ field to retrieve super constructor.
1221         Currently, it is handled as an usual getter call to a generic function. And DFG just emits
1222         Call node for this. It is inefficient since typically we know the `prototype` of the given
1223         object when accessing `object.__proto__` since we emit CheckStructure for this `object`.
1224         If Structure has mono proto, we can immediately fold it to constant value. If it is poly proto,
1225         we can still change this to efficient access to poly proto slot.
1226
1227         This patch implements GetPrototypeOf DFG node. This node efficiently accesses to prototype of
1228         the given object. And in AI and ByteCodeParser phase, we attempt to fold it to constant.
1229         ByteCodeParser's folding is a bit important since we have `callee.__proto__` code to get super
1230         constructor. If we can change this to constant, we can reify CallLinkInfo with this constant.
1231         This paves the way to optimizing ArrayConstructor super calls[1], which is particularly important
1232         for ARES-6 ML.
1233
1234         And we also optimize Reflect.getPrototypeOf and Object.getPrototypeOf with this GetPrototypeOf node.
1235
1236         Currently, __proto__ access for poly proto object is not handled well in IC. But we add code handling
1237         poly proto in GetPrototypeOf since Reflect.getPrototypeOf and Object.getPrototypeOf can use it.
1238         Once IC starts handling poly proto & intrinsic getter well, this code will be used for that too.
1239
1240         This patch improves SixSpeed super.es6 by 3.42x.
1241
1242                                  baseline                  patched
1243
1244         super.es6           123.6666+-3.9917     ^     36.1684+-1.0351        ^ definitely 3.4192x faster
1245
1246         [1]: https://bugs.webkit.org/show_bug.cgi?id=178064
1247
1248         * dfg/DFGAbstractInterpreterInlines.h:
1249         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1250         * dfg/DFGByteCodeParser.cpp:
1251         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
1252         (JSC::DFG::ByteCodeParser::handleIntrinsicGetter):
1253         (JSC::DFG::ByteCodeParser::handleGetById):
1254         * dfg/DFGClobberize.h:
1255         (JSC::DFG::clobberize):
1256         * dfg/DFGDoesGC.cpp:
1257         (JSC::DFG::doesGC):
1258         * dfg/DFGFixupPhase.cpp:
1259         (JSC::DFG::FixupPhase::fixupNode):
1260         (JSC::DFG::FixupPhase::fixupGetPrototypeOf):
1261         * dfg/DFGHeapLocation.cpp:
1262         (WTF::printInternal):
1263         * dfg/DFGHeapLocation.h:
1264         * dfg/DFGNode.h:
1265         (JSC::DFG::Node::hasHeapPrediction):
1266         (JSC::DFG::Node::shouldSpeculateFunction):
1267         * dfg/DFGNodeType.h:
1268         * dfg/DFGOperations.cpp:
1269         * dfg/DFGOperations.h:
1270         * dfg/DFGPredictionPropagationPhase.cpp:
1271         * dfg/DFGSafeToExecute.h:
1272         (JSC::DFG::safeToExecute):
1273         * dfg/DFGSpeculativeJIT.cpp:
1274         (JSC::DFG::SpeculativeJIT::speculateFunction):
1275         (JSC::DFG::SpeculativeJIT::speculateFinalObject):
1276         (JSC::DFG::SpeculativeJIT::compileGetPrototypeOf):
1277         * dfg/DFGSpeculativeJIT.h:
1278         * dfg/DFGSpeculativeJIT32_64.cpp:
1279         (JSC::DFG::SpeculativeJIT::compile):
1280         * dfg/DFGSpeculativeJIT64.cpp:
1281         (JSC::DFG::SpeculativeJIT::compile):
1282         * ftl/FTLCapabilities.cpp:
1283         (JSC::FTL::canCompile):
1284         * ftl/FTLLowerDFGToB3.cpp:
1285         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1286         (JSC::FTL::DFG::LowerDFGToB3::compileGetPrototypeOf):
1287         (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
1288         * jit/IntrinsicEmitter.cpp:
1289         (JSC::IntrinsicGetterAccessCase::canEmitIntrinsicGetter):
1290         (JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter):
1291         * runtime/Intrinsic.cpp:
1292         (JSC::intrinsicName):
1293         * runtime/Intrinsic.h:
1294         * runtime/JSGlobalObject.cpp:
1295         (JSC::JSGlobalObject::init):
1296         * runtime/JSGlobalObjectFunctions.cpp:
1297         (JSC::globalFuncProtoGetter):
1298         * runtime/JSGlobalObjectFunctions.h:
1299         * runtime/ObjectConstructor.cpp:
1300         * runtime/ReflectObject.cpp:
1301
1302 2017-10-17  Keith Miller  <keith_miller@apple.com>
1303
1304         Change WebCore sources to work with unified source builds
1305         https://bugs.webkit.org/show_bug.cgi?id=178229
1306
1307         Rubber stamped by Tim Horton.
1308
1309         * Configurations/FeatureDefines.xcconfig:
1310
1311 2017-10-15  Filip Pizlo  <fpizlo@apple.com>
1312
1313         Make some asserts into release asserts
1314         https://bugs.webkit.org/show_bug.cgi?id=178324
1315
1316         Reviewed by Saam Barati.
1317         
1318         These asserts are not on perf critical paths, so they might as well be release asserts.
1319
1320         * runtime/DataView.h:
1321         (JSC::DataView::get):
1322         (JSC::DataView::set):
1323
1324 2017-10-16  JF Bastien  <jfbastien@apple.com>
1325
1326         JSRunLoopTimer: reduce likely race when used improperly
1327         https://bugs.webkit.org/show_bug.cgi?id=178298
1328         <rdar://problem/32899816>
1329
1330         Reviewed by Saam Barati.
1331
1332         If an API user sets a timer on JSRunLoopTimer, and then racily
1333         destroys the JSRunLoopTimer while the timer is firing then it's
1334         possible for timerDidFire to cause a use-after-free and / or crash
1335         because e.g. m_apiLock becomes a nullptr while timerDidFire is
1336         executing. That results from an invalid use of JSRunLoopTimer, but
1337         we should try to be more resilient for that type of misuse because
1338         it's not necessarily easy to catch by inspection.
1339
1340         With this change the only remaining race is if the timer fires,
1341         and then only timerDidFire's prologue executes, but not the load
1342         of the m_apiLock pointer from `this`. It's a much smaller race.
1343
1344         Separately, I'll reach out to API users who are seemingly misusing
1345         the API.
1346
1347         * runtime/JSRunLoopTimer.cpp:
1348         (JSC::JSRunLoopTimer::timerDidFire): put m_apiLock on the stack,
1349         and checks for nullptr. This prevents loading it twice off of
1350         `this` and turns a nullptr deref into "just" a use-after-free.
1351         (JSC::JSRunLoopTimer::~JSRunLoopTimer): acquire m_apiLock before
1352         calling m_vm->unregisterRunLoopTimer(this), which in turn does
1353         CFRunLoopRemoveTimer / CFRunLoopTimerInvalidate. This prevents
1354         timerDidFire from doing much while the timers are un-registered.
1355         ~JSRunLoopTimer also needs to set m_apiLock to nullptr before
1356         releasing the lock, so it needs its own local copy.
1357
1358 2017-10-15  Yusuke Suzuki  <utatane.tea@gmail.com>
1359
1360         [JSC] Perform module specifier validation at parsing time
1361         https://bugs.webkit.org/show_bug.cgi?id=178256
1362
1363         Reviewed by Darin Adler.
1364
1365         This patch make module loader's `resolve` operation synchronous. And we validate
1366         module's requested module names when instantiating the module instead of satisfying
1367         module's dependencies. This change is not observable to users. But this is precise
1368         to the spec and this optimizes & simplifies the current module loader a bit by
1369         reducing object allocations.
1370
1371         Previously, we have an object called pair in the module loader. This is pair of
1372         module's name and module's record. And we use it to link one module to dependent
1373         modules. Now, it is replaced with module's registry entry.
1374
1375         We also change our loader functions to take a registry entry instead of a module key.
1376         Previous design is due to the consideration that these APIs may be exposed to users
1377         in whatwg/loader spec. However, this won't happen. This change removes unnecessary
1378         repeatedly hash map lookups.
1379
1380         * builtins/ModuleLoaderPrototype.js:
1381         (globalPrivate.newRegistryEntry):
1382         (requestFetch):
1383         (requestInstantiate):
1384         (requestSatisfy):
1385         (link):
1386         (moduleEvaluation):
1387         (loadModule):
1388         * jsc.cpp:
1389         (GlobalObject::moduleLoaderResolve):
1390         * runtime/AbstractModuleRecord.cpp:
1391         (JSC::AbstractModuleRecord::finishCreation):
1392         (JSC::AbstractModuleRecord::hostResolveImportedModule):
1393         * runtime/JSGlobalObject.h:
1394         * runtime/JSModuleLoader.cpp:
1395         (JSC::JSModuleLoader::resolveSync):
1396         (JSC::JSModuleLoader::resolve):
1397         * runtime/JSModuleLoader.h:
1398         * runtime/ModuleLoaderPrototype.cpp:
1399         (JSC::moduleLoaderPrototypeResolveSync):
1400
1401 2017-10-14  Devin Rousso  <webkit@devinrousso.com>
1402
1403         Web Inspector: provide a way to enable/disable event listeners
1404         https://bugs.webkit.org/show_bug.cgi?id=177451
1405
1406         Reviewed by Joseph Pecoraro.
1407
1408         * inspector/protocol/DOM.json:
1409         Add `setEventListenerDisabled` command that enables/disables a specific event listener
1410         during event dispatch. When a disabled event listener is fired, the listener's callback will
1411         not be called.
1412
1413 2017-10-14  Yusuke Suzuki  <utatane.tea@gmail.com>
1414
1415         Reland "Add Above/Below comparisons for UInt32 patterns"
1416         https://bugs.webkit.org/show_bug.cgi?id=177281
1417
1418         Reviewed by Saam Barati.
1419
1420         We reland this patch without DFGStrengthReduction change to see what causes
1421         regression in the iOS bot.
1422
1423         Sometimes, we would like to have UInt32 operations in JS. While VM does
1424         not support UInt32 nicely, VM supports efficient Int32 operations. As long
1425         as signedness does not matter, we can just perform Int32 operations instead
1426         and recognize its bit pattern as UInt32.
1427
1428         But of course, some operations respect signedness. The most frequently
1429         used one is comparison. Octane/zlib performs UInt32 comparison by performing
1430         `val >>> 0`. It emits op_urshift and op_unsigned. op_urshift produces
1431         UInt32 in Int32 form. And op_unsigned will generate Double value if
1432         the generated Int32 is < 0 (which should be UInt32).
1433
1434         There is a chance for optimization. The given code pattern is the following.
1435
1436             op_unsigned(op_urshift(@1)) lessThan:< op_unsigned(op_urshift(@2))
1437
1438         This can be converted to the following.
1439
1440             op_urshift(@1) below:< op_urshift(@2)
1441
1442         The above conversion is nice since
1443
1444         1. We can avoid op_unsigned. This could be unsignedness check in DFG. Since
1445         this check depends on the value of Int32, dropping this check is not as easy as
1446         removing Int32 edge filters.
1447
1448         2. We can perform unsigned comparison in Int32 form. We do not need to convert
1449         them to DoubleRep.
1450
1451         Since the above comparison exists in Octane/zlib's *super* hot path, dropping
1452         op_unsigned offers huge win.
1453
1454         At first, my patch attempts to convert the above thing in DFG pipeline.
1455         However it poses several problems.
1456
1457         1. MovHint is not well removed. It makes UInt32ToNumber (which is for op_unsigned) live.
1458         2. UInt32ToNumber could cause an OSR exit. So if we have the following nodes,
1459
1460             2: UInt32ToNumber(@0)
1461             3: MovHint(@2, xxx)
1462             4: UInt32ToNumber(@1)
1463             5: MovHint(@1, xxx)
1464
1465         we could drop @5's MovHint. But @3 is difficult since @4 can exit.
1466
1467         So, instead, we start introducing a simple optimization in the bytecode compiler.
1468         It performs pattern matching for op_urshift and comparison to drop op_unsigned.
1469         We adds op_below and op_above families to bytecodes. They only accept Int32 and
1470         perform unsigned comparison.
1471
1472         This offers 4% performance improvement in Octane/zlib.
1473
1474                                     baseline                  patched
1475
1476         zlib           x2     431.07483+-16.28434       414.33407+-9.38375         might be 1.0404x faster
1477
1478         * bytecode/BytecodeDumper.cpp:
1479         (JSC::BytecodeDumper<Block>::printCompareJump):
1480         (JSC::BytecodeDumper<Block>::dumpBytecode):
1481         * bytecode/BytecodeDumper.h:
1482         * bytecode/BytecodeList.json:
1483         * bytecode/BytecodeUseDef.h:
1484         (JSC::computeUsesForBytecodeOffset):
1485         (JSC::computeDefsForBytecodeOffset):
1486         * bytecode/Opcode.h:
1487         (JSC::isBranch):
1488         * bytecode/PreciseJumpTargetsInlines.h:
1489         (JSC::extractStoredJumpTargetsForBytecodeOffset):
1490         * bytecompiler/BytecodeGenerator.cpp:
1491         (JSC::BytecodeGenerator::emitJumpIfTrue):
1492         (JSC::BytecodeGenerator::emitJumpIfFalse):
1493         * bytecompiler/NodesCodegen.cpp:
1494         (JSC::BinaryOpNode::emitBytecode):
1495         * dfg/DFGAbstractInterpreterInlines.h:
1496         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1497         * dfg/DFGByteCodeParser.cpp:
1498         (JSC::DFG::ByteCodeParser::parseBlock):
1499         * dfg/DFGCapabilities.cpp:
1500         (JSC::DFG::capabilityLevel):
1501         * dfg/DFGClobberize.h:
1502         (JSC::DFG::clobberize):
1503         * dfg/DFGDoesGC.cpp:
1504         (JSC::DFG::doesGC):
1505         * dfg/DFGFixupPhase.cpp:
1506         (JSC::DFG::FixupPhase::fixupNode):
1507         * dfg/DFGIntegerRangeOptimizationPhase.cpp:
1508         * dfg/DFGNodeType.h:
1509         * dfg/DFGPredictionPropagationPhase.cpp:
1510         * dfg/DFGSafeToExecute.h:
1511         (JSC::DFG::safeToExecute):
1512         * dfg/DFGSpeculativeJIT.cpp:
1513         (JSC::DFG::SpeculativeJIT::compileCompareUnsigned):
1514         * dfg/DFGSpeculativeJIT.h:
1515         * dfg/DFGSpeculativeJIT32_64.cpp:
1516         (JSC::DFG::SpeculativeJIT::compile):
1517         * dfg/DFGSpeculativeJIT64.cpp:
1518         (JSC::DFG::SpeculativeJIT::compile):
1519         * dfg/DFGValidate.cpp:
1520         * ftl/FTLCapabilities.cpp:
1521         (JSC::FTL::canCompile):
1522         * ftl/FTLLowerDFGToB3.cpp:
1523         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1524         (JSC::FTL::DFG::LowerDFGToB3::compileCompareBelow):
1525         (JSC::FTL::DFG::LowerDFGToB3::compileCompareBelowEq):
1526         * jit/JIT.cpp:
1527         (JSC::JIT::privateCompileMainPass):
1528         * jit/JIT.h:
1529         * jit/JITArithmetic.cpp:
1530         (JSC::JIT::emit_op_below):
1531         (JSC::JIT::emit_op_beloweq):
1532         (JSC::JIT::emit_op_jbelow):
1533         (JSC::JIT::emit_op_jbeloweq):
1534         (JSC::JIT::emit_compareUnsignedAndJump):
1535         (JSC::JIT::emit_compareUnsigned):
1536         * jit/JITArithmetic32_64.cpp:
1537         (JSC::JIT::emit_compareUnsignedAndJump):
1538         (JSC::JIT::emit_compareUnsigned):
1539         * llint/LowLevelInterpreter.asm:
1540         * llint/LowLevelInterpreter32_64.asm:
1541         * llint/LowLevelInterpreter64.asm:
1542         * parser/Nodes.h:
1543         (JSC::ExpressionNode::isBinaryOpNode const):
1544
1545 2017-10-12  Yusuke Suzuki  <utatane.tea@gmail.com>
1546
1547         WebAssembly: Wasm functions should have either JSFunctionType or TypeOfShouldCallGetCallData
1548         https://bugs.webkit.org/show_bug.cgi?id=178210
1549
1550         Reviewed by Saam Barati.
1551
1552         In Wasm, we have two JS functions exposed to users: WebAssemblyFunction and WebAssemblyWrapperFunction.
1553         The former is an exported wasm function and the latter is an imported & exported function. Since they
1554         have [[Call]], they should be categorized into "function" in typeof operation.
1555
1556         However, these functions do not implement our function protocol correctly. They inherit JSFunction.
1557         But JSType of WebAssemblyFunction is WebAssemblyFunctionType, and one of WebAssemblyWrapperFunction is
1558         ObjectType. Since both do not have TypeOfShouldCallGetCallData, they return "object" when performing
1559         typeof operation.
1560
1561         In this patch, we address the above issue by the following 2 fixes.
1562
1563         1. We add TypeOfShouldCallGetCallData to WebAssemblyFunction. This is the same way how we implement
1564         InternalFunction. Since WebAssemblyFunction requires WebAssemblyFunctionType for fast checking in Wasm
1565         implementation, we cannot make this JSFunctionType.
1566
1567         2. On the other hand, WebAssemblyWrapperFunction does not require a specific JSType. So this patch
1568         changes JSType of WebAssemblyWrapperFunction to JSFunctionType. JSFunctionType can be usable for derived
1569         classes of JSFunction (e.g. JSCustomGetterSetterFunction).
1570
1571         * wasm/js/WebAssemblyFunction.h:
1572         (JSC::WebAssemblyFunction::signatureIndex const): Deleted.
1573         (JSC::WebAssemblyFunction::wasmEntrypointLoadLocation const): Deleted.
1574         (JSC::WebAssemblyFunction::callableFunction const): Deleted.
1575         (JSC::WebAssemblyFunction::jsEntrypoint): Deleted.
1576         (JSC::WebAssemblyFunction::offsetOfWasmEntrypointLoadLocation): Deleted.
1577         * wasm/js/WebAssemblyWrapperFunction.cpp:
1578         (JSC::WebAssemblyWrapperFunction::createStructure):
1579         * wasm/js/WebAssemblyWrapperFunction.h:
1580         (JSC::WebAssemblyWrapperFunction::signatureIndex const): Deleted.
1581         (JSC::WebAssemblyWrapperFunction::wasmEntrypointLoadLocation const): Deleted.
1582         (JSC::WebAssemblyWrapperFunction::callableFunction const): Deleted.
1583         (JSC::WebAssemblyWrapperFunction::function): Deleted.
1584
1585 2017-10-12  Per Arne Vollan  <pvollan@apple.com>
1586
1587         [Win64] JSC compile error.
1588         https://bugs.webkit.org/show_bug.cgi?id=178213
1589
1590         Reviewed by Alex Christensen.
1591
1592         Add static cast from int64 to uintptr_t.
1593
1594         * dfg/DFGOSRExit.cpp:
1595         (JSC::DFG::OSRExit::executeOSRExit):
1596
1597 2017-09-29  Filip Pizlo  <fpizlo@apple.com>
1598
1599         Enable gigacage on iOS
1600         https://bugs.webkit.org/show_bug.cgi?id=177586
1601
1602         Reviewed by JF Bastien.
1603
1604         The hardest part of enabling Gigacage on iOS is that it requires loading global variables while
1605         executing JS, so the LLInt needs to know how to load from global variables on all platforms that
1606         have Gigacage. So, this teaches ARM64 how to load from global variables.
1607         
1608         Also, this makes the code handle disabling the gigacage a bit better.
1609
1610         * ftl/FTLLowerDFGToB3.cpp:
1611         (JSC::FTL::DFG::LowerDFGToB3::caged):
1612         * jit/AssemblyHelpers.h:
1613         (JSC::AssemblyHelpers::cage):
1614         (JSC::AssemblyHelpers::cageConditionally):
1615         * offlineasm/arm64.rb:
1616         * offlineasm/asm.rb:
1617         * offlineasm/instructions.rb:
1618
1619 2017-10-11  Sam Weinig  <sam@webkit.org>
1620
1621         Remove out-parameter variants of copyToVector
1622         https://bugs.webkit.org/show_bug.cgi?id=178155
1623
1624         Reviewed by Tim Horton.
1625
1626         * inspector/ScriptDebugServer.cpp:
1627         (Inspector::ScriptDebugServer::dispatchBreakpointActionLog):
1628         (Inspector::ScriptDebugServer::dispatchBreakpointActionSound):
1629         (Inspector::ScriptDebugServer::dispatchBreakpointActionProbe):
1630         (Inspector::ScriptDebugServer::dispatchDidParseSource):
1631         (Inspector::ScriptDebugServer::dispatchFailedToParseSource):
1632         (Inspector::ScriptDebugServer::dispatchFunctionToListeners):
1633             
1634             Replace out-parameter based copyToVector, with one that returns a Vector.
1635
1636 2017-10-12  Yusuke Suzuki  <utatane.tea@gmail.com>
1637
1638         Support integrity="" on module scripts
1639         https://bugs.webkit.org/show_bug.cgi?id=177959
1640
1641         Reviewed by Sam Weinig.
1642
1643         This patch adds Subresource Integrity check for module scripts. Currently,
1644         only top-level module can be verified with integrity parameter since there
1645         is no way to perform integrity check onto the imported modules.
1646
1647         In JSC side, we add `parameters` to the entry point of the module loader
1648         pipeline. This is fetching parameters and used when fetching modules.
1649
1650         We separately pass this parameters to the pipeline along with the script fetcher.
1651         The script fetcher is only one for module graph since this is the initiator of
1652         this module graph loading. On the other hand, this parameters is for each
1653         module fetching. While setting "integrity" parameters to this script fetcher is
1654         sufficient to pass parameters to top-level-module's fetching, it is not enough
1655         for the future extension.
1656
1657         In the future, we will investigate a way to pass parameters to each non-top-level
1658         module. At that time, this `parameters` should be per-module. This is because
1659         "integrity" value should be different for each module. For example, we will accept
1660         some form of syntax to add parameters to `import`. Some proposed syntax is like
1661         https://discourse.wicg.io/t/specifying-nonce-or-integrity-when-importing-modules/1861
1662
1663         import "./xxx.js" integrity "xxxxxxx"
1664
1665         In this case, this `parameters` will be passed to "./xxx.js" module fetching. This
1666         `parameters` should be different from the one of top-level-module's one. That's why
1667         we need per-module `parameters` and why this patch adds `parameters` to the module pipeline.
1668
1669         On the other hand, we also want to keep script fetcher. This `per-module-graph` thing
1670         is important to offer module-graph-wide information. For example, import.meta would
1671         have `import.meta.scriptElement`, which is the script element fetching the module graph
1672         including this. So, we keep the both, script fetcher and parameters.
1673         https://github.com/tc39/proposal-import-meta
1674
1675         This parameters will be finally used by pipeline's fetch hook, and WebCore side
1676         can use this parameters to fetch modules.
1677
1678         We also further clean up the module pipeline by dropping unnecessary features.
1679
1680         * JavaScriptCore.xcodeproj/project.pbxproj:
1681         * Sources.txt:
1682         * builtins/ModuleLoaderPrototype.js:
1683         (requestFetch):
1684         (requestInstantiate):
1685         (requestSatisfy):
1686         (loadModule):
1687         (loadAndEvaluateModule):
1688         This loadAndEvaluateModule should be implemented by just calling loadModule and
1689         linkAndEvaluateModule. We can drop requestReady and requestLink.
1690
1691         (requestLink): Deleted.
1692         (requestImportModule): Deleted.
1693         * jsc.cpp:
1694         (GlobalObject::moduleLoaderImportModule):
1695         (GlobalObject::moduleLoaderFetch):
1696         import and fetch hook takes parameters. Currently, we always pass `undefined` for
1697         import hook. When dynamic `import()` is extended to accept additional parameters
1698         like integrity, this parameters will be replaced with the actual value.
1699
1700         (functionLoadModule):
1701         (runWithOptions):
1702         * runtime/Completion.cpp:
1703         (JSC::loadAndEvaluateModule):
1704         (JSC::loadModule):
1705         (JSC::importModule):
1706         * runtime/Completion.h:
1707         * runtime/JSGlobalObject.h:
1708         * runtime/JSGlobalObjectFunctions.cpp:
1709         (JSC::globalFuncImportModule):
1710         * runtime/JSModuleLoader.cpp:
1711         (JSC::JSModuleLoader::loadAndEvaluateModule):
1712         (JSC::JSModuleLoader::loadModule):
1713         (JSC::JSModuleLoader::requestImportModule):
1714         (JSC::JSModuleLoader::importModule):
1715         (JSC::JSModuleLoader::fetch):
1716         * runtime/JSModuleLoader.h:
1717         * runtime/JSScriptFetchParameters.cpp: Added.
1718         (JSC::JSScriptFetchParameters::destroy):
1719         * runtime/JSScriptFetchParameters.h: Added.
1720         (JSC::JSScriptFetchParameters::createStructure):
1721         (JSC::JSScriptFetchParameters::create):
1722         (JSC::JSScriptFetchParameters::parameters const):
1723         (JSC::JSScriptFetchParameters::JSScriptFetchParameters):
1724         Add ScriptFetchParameters' JSCell wrapper, JSScriptFetchParameters.
1725         It is used in the module pipeline.
1726
1727         * runtime/JSType.h:
1728         * runtime/ModuleLoaderPrototype.cpp:
1729         (JSC::moduleLoaderPrototypeFetch):
1730         * runtime/ScriptFetchParameters.h: Added.
1731         (JSC::ScriptFetchParameters::~ScriptFetchParameters):
1732         Add ScriptFetchParameters. We can define our own custom ScriptFetchParameters
1733         by inheriting this class. WebCore creates ModuleFetchParameters by inheriting
1734         this.
1735
1736         * runtime/VM.cpp:
1737         (JSC::VM::VM):
1738         * runtime/VM.h:
1739
1740 2017-10-11  Yusuke Suzuki  <utatane.tea@gmail.com>
1741
1742         import.meta should not be assignable
1743         https://bugs.webkit.org/show_bug.cgi?id=178202
1744
1745         Reviewed by Saam Barati.
1746
1747         `import.meta` cannot be used for LHS. This patch adds MetaPropertyNode
1748         and make NewTargetNode and ImportMetaNode as derived classes of MetaPropertyNode.
1749         We change the parser not to allow assignments for MetaPropertyNode.
1750
1751         * bytecompiler/NodesCodegen.cpp:
1752         (JSC::ImportMetaNode::emitBytecode):
1753         * parser/ASTBuilder.h:
1754         (JSC::ASTBuilder::createImportMetaExpr):
1755         (JSC::ASTBuilder::isMetaProperty):
1756         (JSC::ASTBuilder::isImportMeta):
1757         * parser/NodeConstructors.h:
1758         (JSC::MetaPropertyNode::MetaPropertyNode):
1759         (JSC::NewTargetNode::NewTargetNode):
1760         (JSC::ImportMetaNode::ImportMetaNode):
1761         * parser/Nodes.h:
1762         (JSC::ExpressionNode::isMetaProperty const):
1763         (JSC::ExpressionNode::isImportMeta const):
1764         * parser/Parser.cpp:
1765         (JSC::Parser<LexerType>::metaPropertyName):
1766         (JSC::Parser<LexerType>::parseAssignmentExpression):
1767         (JSC::Parser<LexerType>::parseMemberExpression):
1768         (JSC::Parser<LexerType>::parseUnaryExpression):
1769         * parser/Parser.h:
1770         * parser/SyntaxChecker.h:
1771         (JSC::SyntaxChecker::createImportMetaExpr):
1772         (JSC::SyntaxChecker::isMetaProperty):
1773         (JSC::SyntaxChecker::isImportMeta):
1774
1775 2017-10-11  Saam Barati  <sbarati@apple.com>
1776
1777         Runtime disable poly proto because it may be a 3-4% Speedometer regression
1778         https://bugs.webkit.org/show_bug.cgi?id=178192
1779
1780         Reviewed by JF Bastien.
1781
1782         * runtime/Options.h:
1783         * runtime/StructureInlines.h:
1784         (JSC::Structure::shouldConvertToPolyProto):
1785
1786 2017-10-11  Commit Queue  <commit-queue@webkit.org>
1787
1788         Unreviewed, rolling out r223113 and r223121.
1789         https://bugs.webkit.org/show_bug.cgi?id=178182
1790
1791         Reintroduced 20% regression on Kraken (Requested by rniwa on
1792         #webkit).
1793
1794         Reverted changesets:
1795
1796         "Enable gigacage on iOS"
1797         https://bugs.webkit.org/show_bug.cgi?id=177586
1798         https://trac.webkit.org/changeset/223113
1799
1800         "Use one virtual allocation for all gigacages and their
1801         runways"
1802         https://bugs.webkit.org/show_bug.cgi?id=178050
1803         https://trac.webkit.org/changeset/223121
1804
1805 2017-10-11  Michael Saboff  <msaboff@apple.com>
1806
1807         Update JavaScriptCore/ucd/CaseFolding.txt to Unicode database 10.0
1808         https://bugs.webkit.org/show_bug.cgi?id=178106
1809
1810         Reviewed by Keith Miller.
1811
1812         * ucd/CaseFolding.txt:
1813
1814 2017-10-11  Caio Lima  <ticaiolima@gmail.com>
1815
1816         Object properties are undefined in super.call() but not in this.call()
1817         https://bugs.webkit.org/show_bug.cgi?id=177230
1818
1819         Reviewed by Saam Barati.
1820
1821         Bytecode generation for "super.call(...)" or "super.apply(...)"
1822         shouldn't be considered as CallFunctionCallDotNode or
1823         ApplyFunctionCallDotNode because they should be considered as common
1824         super property access as any other function. According to spec[1],
1825         "super" is not refering to parent constructor.
1826
1827         [1] - https://tc39.github.io/ecma262/#sec-super-keyword-runtime-semantics-evaluation
1828
1829         * parser/ASTBuilder.h:
1830         (JSC::ASTBuilder::makeFunctionCallNode):
1831         * parser/Parser.cpp:
1832         (JSC::Parser<LexerType>::parseMemberExpression):
1833         * parser/SyntaxChecker.h:
1834         (JSC::SyntaxChecker::makeFunctionCallNode):
1835
1836 2017-10-11  Yusuke Suzuki  <utatane.tea@gmail.com>
1837
1838         [JSC] Drop Instantiate hook in ES6 module loader
1839         https://bugs.webkit.org/show_bug.cgi?id=178162
1840
1841         Reviewed by Sam Weinig.
1842
1843         This patch is a part of patch series for module loader refactoring to adopt
1844         integrity="" parameters and introduce new whatwg module import mechanism.
1845
1846         In this patch, we drop instantiate hook in module loader. This hook is originally
1847         introduced because it is defined in whatwg/loader spec. But this hook is not
1848         used in our implementation, and this hook won't be used since (1) whatwg/loader
1849         spec is abandoned, and (2) this type of hooks should be done in Service Workers.
1850
1851         In addition, this patch applies some cleaning up of our module loader JS code
1852         to simplify things. This change paves the way to more efficient loader implementation
1853         with great flexibility to adopt integrity="" parameters.
1854
1855         * builtins/ModuleLoaderPrototype.js:
1856         (requestInstantiate):
1857         (provideFetch):
1858         provide is changed to provideFetch since we only used this function with Fetch stage parameter.
1859
1860         (fulfillInstantiate): Deleted.
1861         (commitInstantiated): Deleted.
1862         (instantiation): Deleted.
1863         They are merged into requestInstantiate code. This is simpler.
1864
1865         (provide): Deleted.
1866         * jsc.cpp:
1867         * runtime/Completion.cpp:
1868         (JSC::loadAndEvaluateModule):
1869         (JSC::loadModule):
1870         * runtime/JSGlobalObject.cpp:
1871         * runtime/JSGlobalObject.h:
1872         * runtime/JSModuleLoader.cpp:
1873         (JSC::JSModuleLoader::provideFetch):
1874         (JSC::JSModuleLoader::provide): Deleted.
1875         Changed to provideFetch.
1876
1877         (JSC::JSModuleLoader::instantiate): Deleted.
1878         Drop this hook.
1879
1880         * runtime/JSModuleLoader.h:
1881         * runtime/ModuleLoaderPrototype.cpp:
1882         (JSC::moduleLoaderPrototypeInstantiate): Deleted.
1883         Drop this hook.
1884
1885 2017-10-10  Saam Barati  <sbarati@apple.com>
1886
1887         Prototype structure transition should be a deferred transition
1888         https://bugs.webkit.org/show_bug.cgi?id=177734
1889
1890         Reviewed by Keith Miller.
1891
1892         Absence ObjectPropertyConditions work by verifying both that the Structure 
1893         does not have a particular property and that its prototype has
1894         remained constant. However, the prototype transition was firing
1895         the transition watchpoint before setting the object's structure.
1896         This meant that isValid for Absence would never return false because
1897         the prototype changed. Clearly this is wrong. The reason this didn't
1898         break OPCs in general is that we'd also check if we could still watch
1899         the OPC. In this case, we can't still watch it because we're inspecting
1900         a structure with an invalidated transition watchpoint. To fix
1901         this weird quirk of the code, I'm making it so that doing a prototype
1902         transition uses the DeferredStructureTransitionWatchpointFire machinery.
1903         
1904         This patch also fixes some dead code that I left in regarding
1905         poly proto in OPC.
1906
1907         * bytecode/PropertyCondition.cpp:
1908         (JSC::PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint const):
1909         * runtime/JSObject.cpp:
1910         (JSC::JSObject::setPrototypeDirect):
1911         * runtime/Structure.cpp:
1912         (JSC::Structure::changePrototypeTransition):
1913         * runtime/Structure.h:
1914
1915 2017-10-10  Robin Morisset  <rmorisset@apple.com>
1916
1917         Avoid allocating useless landingBlocks in DFGByteCodeParser::handleInlining()
1918         https://bugs.webkit.org/show_bug.cgi?id=177926
1919
1920         Reviewed by Saam Barati.
1921
1922         When doing polyvariant inlining, there used to be a landing block for each callee, each of which was then linked to a continuation block.
1923         With this change, we allocate the continuation block first, and pass it to the inlining routine so that op_ret in the callee link directly to it.
1924         The only subtlety is that when inlining an intrinsic we must do the jump by hand, and also remember to call processSetLocalQueue with nextOffset before it.
1925
1926         * dfg/DFGByteCodeParser.cpp:
1927         (JSC::DFG::ByteCodeParser::inlineCall):
1928         (JSC::DFG::ByteCodeParser::attemptToInlineCall):
1929         (JSC::DFG::ByteCodeParser::handleInlining):
1930         (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
1931         (JSC::DFG::ByteCodeParser::parse):
1932
1933 2017-10-10  Guillaume Emont  <guijemont@igalia.com>
1934
1935         Fix compilation when MASM_PROBE (and therefore DFG) are disabled
1936         https://bugs.webkit.org/show_bug.cgi?id=178134
1937
1938         Reviewed by Saam Barati.
1939
1940         * bytecode/CodeBlock.cpp:
1941         * bytecode/CodeBlock.h:
1942         Disable some code when building without DFG_JIT.
1943
1944 2017-10-10  Sam Weinig  <sam@webkit.org>
1945
1946         Replace copyKeysToVector/copyValuesToVector with copyToVector(map.keys())/copyToVector(map.values())
1947         https://bugs.webkit.org/show_bug.cgi?id=178102
1948
1949         Reviewed by Tim Horton.
1950
1951         * inspector/agents/InspectorDebuggerAgent.cpp:
1952         (Inspector::InspectorDebuggerAgent::clearInspectorBreakpointState):
1953
1954 2017-10-10  Michael Saboff  <msaboff@apple.com>
1955
1956         Unreviewed build fix.
1957
1958         Removed unused lambda capture.
1959
1960         * yarr/YarrPattern.cpp:
1961         (JSC::Yarr::CharacterClassConstructor::appendInverted):
1962
1963 2017-10-10  Saam Barati  <sbarati@apple.com>
1964
1965         The prototype cache should be aware of the Executable it generates a Structure for
1966         https://bugs.webkit.org/show_bug.cgi?id=177907
1967
1968         Reviewed by Filip Pizlo.
1969
1970         This patch renames PrototypeMap to StructureCache because
1971         it is no longer a map of the prototypes in the VM. It's
1972         only used to cache Structures during object construction.
1973         
1974         The main change of this patch is to guarantee that Structures generated
1975         by the create_this originating from different two different Executables'
1976         bytecode won't hash-cons to the same thing. Previously, we could hash-cons
1977         them depending on the JSObject* prototype pointer. This would cause the last
1978         thing that hash-consed to overwrite the Structure's poly proto watchpoint. This
1979         happened because when we initialize a JSFunction's ObjectAllocationProfile,
1980         we set the resulting Structure's poly proto watchpoint. This could cause a Structure
1981         generating from some Executable e1 to end up with the poly proto watchpoint
1982         for another Executable e2 simply because JSFunctions backed by e1 and e2
1983         shared the same prototype. Then, based on profiling information, we may fire the
1984         wrong Executable's poly proto watchpoint. This patch fixes this bug by
1985         guaranteeing that Structures generating from create_this for different
1986         Executables are unique even if they share the same prototype by adding
1987         the FunctionExecutable* as another field in PrototypeKey.
1988
1989         * JavaScriptCore.xcodeproj/project.pbxproj:
1990         * Sources.txt:
1991         * bytecode/InternalFunctionAllocationProfile.h:
1992         (JSC::InternalFunctionAllocationProfile::createAllocationStructureFromBase):
1993         * bytecode/ObjectAllocationProfile.cpp:
1994         (JSC::ObjectAllocationProfile::initializeProfile):
1995         * dfg/DFGOperations.cpp:
1996         * runtime/CommonSlowPaths.cpp:
1997         (JSC::SLOW_PATH_DECL):
1998         * runtime/InternalFunction.cpp:
1999         (JSC::InternalFunction::createSubclassStructureSlow):
2000         * runtime/IteratorOperations.cpp:
2001         (JSC::createIteratorResultObjectStructure):
2002         * runtime/JSBoundFunction.cpp:
2003         (JSC::getBoundFunctionStructure):
2004         * runtime/JSGlobalObject.cpp:
2005         (JSC::JSGlobalObject::init):
2006         * runtime/ObjectConstructor.h:
2007         (JSC::constructEmptyObject):
2008         * runtime/PrototypeKey.h:
2009         (JSC::PrototypeKey::PrototypeKey):
2010         (JSC::PrototypeKey::executable const):
2011         (JSC::PrototypeKey::operator== const):
2012         (JSC::PrototypeKey::hash const):
2013         * runtime/PrototypeMap.cpp: Removed.
2014         * runtime/PrototypeMap.h: Removed.
2015         * runtime/StructureCache.cpp: Copied from Source/JavaScriptCore/runtime/PrototypeMap.cpp.
2016         (JSC::StructureCache::createEmptyStructure):
2017         (JSC::StructureCache::emptyStructureForPrototypeFromBaseStructure):
2018         (JSC::StructureCache::emptyObjectStructureForPrototype):
2019         (JSC::PrototypeMap::createEmptyStructure): Deleted.
2020         (JSC::PrototypeMap::emptyStructureForPrototypeFromBaseStructure): Deleted.
2021         (JSC::PrototypeMap::emptyObjectStructureForPrototype): Deleted.
2022         * runtime/StructureCache.h: Copied from Source/JavaScriptCore/runtime/PrototypeMap.h.
2023         (JSC::StructureCache::StructureCache):
2024         (JSC::PrototypeMap::PrototypeMap): Deleted.
2025         * runtime/VM.cpp:
2026         (JSC::VM::VM):
2027         * runtime/VM.h:
2028
2029 2017-10-09  Yusuke Suzuki  <utatane.tea@gmail.com>
2030
2031         `async` should be able to be used as an imported binding name
2032         https://bugs.webkit.org/show_bug.cgi?id=176573
2033
2034         Reviewed by Saam Barati.
2035
2036         Previously, we have ASYNC keyword in the parser. This is introduced only for performance,
2037         and ECMA262 spec does not categorize "async" to keyword. This makes parser code complicated,
2038         since ASYNC should be handled as IDENT. If we missed this ASYNC keyword, we cause a bug.
2039         For example, import declaration failed to bind imported binding to the name "async" because
2040         the parser considered ASYNC as keyword.
2041
2042         This patch removes ASYNC keyword from the parser. By carefully handling ASYNC, we can keep
2043         the current performance without using this ASYNC keyword.
2044
2045         We also add `escaped` field to token data since contextual keyword is valid only if it does
2046         not contain any escape sequences. We fix bunch of contextual keyword use with this fix too
2047         e.g. `of in for-of`. This improves test262 score.
2048
2049         * parser/Keywords.table:
2050         * parser/Lexer.cpp:
2051         (JSC::Lexer<LChar>::parseIdentifier):
2052         (JSC::Lexer<UChar>::parseIdentifier):
2053         (JSC::Lexer<CharacterType>::parseIdentifierSlowCase):
2054         * parser/Parser.cpp:
2055         (JSC::Parser<LexerType>::parseStatementListItem):
2056         (JSC::Parser<LexerType>::parseForStatement):
2057         (JSC::Parser<LexerType>::parseStatement):
2058         (JSC::Parser<LexerType>::maybeParseAsyncFunctionDeclarationStatement):
2059         (JSC::Parser<LexerType>::parseClass):
2060         (JSC::Parser<LexerType>::parseExportDeclaration):
2061         (JSC::Parser<LexerType>::parseAssignmentExpression):
2062         (JSC::Parser<LexerType>::parseProperty):
2063         (JSC::Parser<LexerType>::parsePrimaryExpression):
2064         (JSC::Parser<LexerType>::parseMemberExpression):
2065         (JSC::Parser<LexerType>::printUnexpectedTokenText):
2066         * parser/Parser.h:
2067         (JSC::Parser::matchContextualKeyword):
2068         * parser/ParserTokens.h:
2069         * runtime/CommonIdentifiers.h:
2070
2071 2017-10-09  Saam Barati  <sbarati@apple.com>
2072
2073         We don't need to clearEmptyObjectStructureForPrototype because JSGlobalObject* is part of the cache's key
2074         https://bugs.webkit.org/show_bug.cgi?id=177987
2075
2076         Reviewed by Filip Pizlo.
2077
2078         * runtime/JSProxy.cpp:
2079         (JSC::JSProxy::setTarget):
2080         * runtime/PrototypeMap.cpp:
2081         (JSC::PrototypeMap::clearEmptyObjectStructureForPrototype): Deleted.
2082         * runtime/PrototypeMap.h:
2083
2084 2017-10-09  Filip Pizlo  <fpizlo@apple.com>
2085
2086         JSCell::didBecomePrototype is racy
2087         https://bugs.webkit.org/show_bug.cgi?id=178110
2088
2089         Reviewed by Saam Barati.
2090         
2091         The indexing type can be modified by any thread using CAS. So, we need to use atomics when
2092         modifying it. We don't need to use atomics when reading it though (since it's just one field).
2093
2094         * runtime/JSCellInlines.h:
2095         (JSC::JSCell::didBecomePrototype):
2096
2097 2017-09-29  Filip Pizlo  <fpizlo@apple.com>
2098
2099         Enable gigacage on iOS
2100         https://bugs.webkit.org/show_bug.cgi?id=177586
2101
2102         Reviewed by JF Bastien.
2103
2104         The hardest part of enabling Gigacage on iOS is that it requires loading global variables while
2105         executing JS, so the LLInt needs to know how to load from global variables on all platforms that
2106         have Gigacage. So, this teaches ARM64 how to load from global variables.
2107         
2108         Also, this makes the code handle disabling the gigacage a bit better.
2109
2110         * ftl/FTLLowerDFGToB3.cpp:
2111         (JSC::FTL::DFG::LowerDFGToB3::caged):
2112         * jit/AssemblyHelpers.h:
2113         (JSC::AssemblyHelpers::cage):
2114         (JSC::AssemblyHelpers::cageConditionally):
2115         * offlineasm/arm64.rb:
2116         * offlineasm/asm.rb:
2117         * offlineasm/instructions.rb:
2118
2119 2017-10-09  Robin Morisset  <rmorisset@apple.com>
2120
2121         Evaluate the benefit of skipping dead code in the DFGByteCodeParser when a function returns in its first block
2122         https://bugs.webkit.org/show_bug.cgi?id=177925
2123
2124         Reviewed by Saam Barati.
2125
2126         We used to do a rather weird "optimisation" in the bytecode parser: when a function would return in its first block,
2127         the rest of the function was skipped. Since it has no actual impact on any benchmarks from what I could see, I removed
2128         that code. It allows some changes to parseBlock(), since it now returns void and no-longer bool (it was returning a boolean that said whether that case happened or not).
2129
2130         * dfg/DFGByteCodeParser.cpp:
2131         (JSC::DFG::ByteCodeParser::parseBlock):
2132         (JSC::DFG::ByteCodeParser::parseCodeBlock):
2133
2134 2017-10-09  Robin Morisset  <rmorisset@apple.com>
2135
2136         Refactor the inliner to simplify block linking
2137         https://bugs.webkit.org/show_bug.cgi?id=177922
2138
2139         Reviewed by Saam Barati.
2140
2141         The biggest refactor changes the way blocks are linked. In DFGByteCodeParser, most terminals (such as Jump or Branch) jump to nullptr initially, and have
2142         some metadata indicating the bytecode index corresponding to their targets. They are later linked to the right basic block using two fields of InlineStackEntry:
2143         - m_unlinkedBlocks is just a worklist of blocks with a terminal that needs to be linked
2144         - m_linkingTargets is a dictionary from bytecode indices to BasicBlock*
2145         Before refactoring, every block was automatically added to both of these fields, for the InlineStackEntry of whatever function allocated it.
2146         This created a significant number of corner cases, such as blocks allocated in a caller, with a terminal written by an inlined callee and pointing to a block in the callee,
2147         or blocks allocated in an inline callee, with a terminal written by the caller after it returns and pointing to a block in the caller, or blocks with a manually linked
2148         terminal that needs to be taken off m_unlinkedBlocks.
2149         I changed things so that blocks are only added to m_unlinkedBlocks when their terminal gets written (see the LAST_OPCODE macro) making it a lot easier to be in the "right" InlineStackEntry,
2150         that is the one that holds their target in its m_linkingTargets field.
2151
2152         There are a few much smaller refactors in this patch:
2153         - parse() is now of type void insted of bool (it was always returning true)
2154         - The 7 and 8 arguments of handleCall were inlined in its 3 arguments version for readability
2155         - The 9 argument version was cleaned up and simplified
2156         - I made separate allocateBlock routines because the little dance with adoptRef(* new BasicBlock(...)) was being repeated in lots of places, and typos in that were a major source of bugs during other refactorings
2157         - Jumps are now created with explicit addJumpTo() functions, providing some sanity checking through asserts and didLink()
2158         - Blocks are only added to m_unlinkedBlocks if they end in a terminal that linkBlock works with (see LAST_OPCODE)
2159
2160         * dfg/DFGByteCodeParser.cpp:
2161         (JSC::DFG::ByteCodeParser::addToGraph):
2162         (JSC::DFG::ByteCodeParser::handleCall):
2163         (JSC::DFG::ByteCodeParser::refineStatically):
2164         (JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
2165         (JSC::DFG::ByteCodeParser::handleVarargsCall):
2166         (JSC::DFG::ByteCodeParser::inlineCall):
2167         (JSC::DFG::ByteCodeParser::attemptToInlineCall):
2168         (JSC::DFG::ByteCodeParser::handleInlining):
2169         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
2170         (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
2171         (JSC::DFG::ByteCodeParser::parseBlock):
2172         (JSC::DFG::ByteCodeParser::parseCodeBlock):
2173         (JSC::DFG::ByteCodeParser::parse):
2174         (JSC::DFG::parse):
2175         (JSC::DFG::ByteCodeParser::cancelLinkingForBlock): Deleted.
2176         * dfg/DFGByteCodeParser.h:
2177         * dfg/DFGPlan.cpp:
2178         (JSC::DFG::Plan::compileInThreadImpl):
2179
2180 2017-10-09  Michael Saboff  <msaboff@apple.com>
2181
2182         Implement RegExp Unicode property escapes
2183         https://bugs.webkit.org/show_bug.cgi?id=172069
2184
2185         Reviewed by JF Bastien.
2186
2187         Added Unicode Properties by extending the existing CharacterClass processing.
2188
2189         Introduced a new Python script, generateYarrUnicodePropertyTables.py, that parses
2190         Unicode Database files to create character class data.  The result is a set of functions
2191         that return character classes, one for each of the required Unicode properties.
2192         There are many cases where many properties are handled by one function, primarily due to
2193         property aliases, but also due to Script_Extension properties that are the same as the
2194         Script property for the same script value.
2195
2196         Extended the BuiltInCharacterClassID enum so it can be used also for Unicode property
2197         character classes.  Unicode properties are the enum value BaseUnicodePropertyID plus a
2198         zero based value, that value being the index to the corrensponding character class
2199         function.  The generation script also creates static hashing tables similar to what we
2200         use for the generated .lut.h lookup table files.  These hashing tables map property
2201         names to the function index.  Using these hashing tables, we can lookup a property
2202         name and if present convert it to a function index.  We add that index to
2203         BaseUnicodePropertyID to create a BuiltInCharacterClassID.
2204
2205         When we do syntax parsing, we convert the property to its corresponding BuiltInCharacterClassID.
2206         When doing real parsing we takes the returned BuiltInCharacterClassID and use it to get
2207         the actual character class by calling the corresponding generated function.
2208
2209         Added a new CharacterClass constructor that can take literal arrays for ranges and matches
2210         to make the creation of large static character classes more efficent.
2211
2212         Since the Unicode character classes typically have more matches and ranges, the character
2213         class matching in the interpreter has been updated to use binary searching for matches and
2214         ranges with more than 6 entries.
2215
2216         * CMakeLists.txt:
2217         * DerivedSources.make:
2218         * JavaScriptCore.xcodeproj/project.pbxproj:
2219         * Scripts/generateYarrUnicodePropertyTables.py: Added.
2220         (openOrExit):
2221         (openUCDFileOrExit):
2222         (verifyUCDFilesExist):
2223         (ceilingToPowerOf2):
2224         (Aliases):
2225         (Aliases.__init__):
2226         (Aliases.parsePropertyAliasesFile):
2227         (Aliases.parsePropertyValueAliasesFile):
2228         (Aliases.globalAliasesFor):
2229         (Aliases.generalCategoryAliasesFor):
2230         (Aliases.generalCategoryForAlias):
2231         (Aliases.scriptAliasesFor):
2232         (Aliases.scriptNameForAlias):
2233         (PropertyData):
2234         (PropertyData.__init__):
2235         (PropertyData.setAliases):
2236         (PropertyData.makeCopy):
2237         (PropertyData.getIndex):
2238         (PropertyData.getCreateFuncName):
2239         (PropertyData.addMatch):
2240         (PropertyData.addRange):
2241         (PropertyData.addMatchUnorderedForMatchesAndRanges):
2242         (PropertyData.addRangeUnorderedForMatchesAndRanges):
2243         (PropertyData.addMatchUnordered):
2244         (PropertyData.addRangeUnordered):
2245         (PropertyData.removeMatchFromRanges):
2246         (PropertyData.removeMatch):
2247         (PropertyData.dumpMatchData):
2248         (PropertyData.dump):
2249         (PropertyData.dumpAll):
2250         (PropertyData.dumpAll.std):
2251         (PropertyData.createAndDumpHashTable):
2252         (Scripts):
2253         (Scripts.__init__):
2254         (Scripts.parseScriptsFile):
2255         (Scripts.parseScriptExtensionsFile):
2256         (Scripts.dump):
2257         (GeneralCategory):
2258         (GeneralCategory.__init__):
2259         (GeneralCategory.createSpecialPropertyData):
2260         (GeneralCategory.findPropertyGroupFor):
2261         (GeneralCategory.addNextCodePoints):
2262         (GeneralCategory.parse):
2263         (GeneralCategory.dump):
2264         (BinaryProperty):
2265         (BinaryProperty.__init__):
2266         (BinaryProperty.parsePropertyFile):
2267         (BinaryProperty.dump):
2268         * Scripts/hasher.py: Added.
2269         (stringHash):
2270         * Sources.txt:
2271         * ucd/DerivedBinaryProperties.txt: Added.
2272         * ucd/DerivedCoreProperties.txt: Added.
2273         * ucd/DerivedNormalizationProps.txt: Added.
2274         * ucd/PropList.txt: Added.
2275         * ucd/PropertyAliases.txt: Added.
2276         * ucd/PropertyValueAliases.txt: Added.
2277         * ucd/ScriptExtensions.txt: Added.
2278         * ucd/Scripts.txt: Added.
2279         * ucd/UnicodeData.txt: Added.
2280         * ucd/emoji-data.txt: Added.
2281         * yarr/Yarr.h:
2282         * yarr/YarrInterpreter.cpp:
2283         (JSC::Yarr::Interpreter::testCharacterClass):
2284         * yarr/YarrParser.h:
2285         (JSC::Yarr::Parser::parseEscape):
2286         (JSC::Yarr::Parser::parseTokens):
2287         (JSC::Yarr::Parser::isUnicodePropertyValueExpressionChar):
2288         (JSC::Yarr::Parser::tryConsumeUnicodePropertyExpression):
2289         * yarr/YarrPattern.cpp:
2290         (JSC::Yarr::CharacterClassConstructor::appendInverted):
2291         (JSC::Yarr::YarrPatternConstructor::atomBuiltInCharacterClass):
2292         (JSC::Yarr::YarrPatternConstructor::atomCharacterClassBuiltIn):
2293         (JSC::Yarr::YarrPattern::errorMessage):
2294         (JSC::Yarr::PatternTerm::dump):
2295         * yarr/YarrPattern.h:
2296         (JSC::Yarr::CharacterRange::CharacterRange):
2297         (JSC::Yarr::CharacterClass::CharacterClass):
2298         (JSC::Yarr::YarrPattern::reset):
2299         (JSC::Yarr::YarrPattern::unicodeCharacterClassFor):
2300         * yarr/YarrUnicodeProperties.cpp: Added.
2301         (JSC::Yarr::HashTable::entry const):
2302         (JSC::Yarr::unicodeMatchPropertyValue):
2303         (JSC::Yarr::unicodeMatchProperty):
2304         (JSC::Yarr::createUnicodeCharacterClassFor):
2305         * yarr/YarrUnicodeProperties.h: Added.
2306
2307 2017-10-09  Commit Queue  <commit-queue@webkit.org>
2308
2309         Unreviewed, rolling out r223015 and r223025.
2310         https://bugs.webkit.org/show_bug.cgi?id=178093
2311
2312         Regressed Kraken on iOS by 20% (Requested by keith_mi_ on
2313         #webkit).
2314
2315         Reverted changesets:
2316
2317         "Enable gigacage on iOS"
2318         https://bugs.webkit.org/show_bug.cgi?id=177586
2319         http://trac.webkit.org/changeset/223015
2320
2321         "Unreviewed, disable Gigacage on ARM64 Linux"
2322         https://bugs.webkit.org/show_bug.cgi?id=177586
2323         http://trac.webkit.org/changeset/223025
2324
2325 2017-10-09  Keith Miller  <keith_miller@apple.com>
2326
2327         Unreviewed, sort unified sources again now that they are numbered numerically rather than lexicographically.
2328
2329         * JavaScriptCore.xcodeproj/project.pbxproj:
2330
2331 2017-10-09  Ryan Haddad  <ryanhaddad@apple.com>
2332
2333         Unreviewed, rolling out r223022.
2334
2335         This change introduced 18 test262 failures.
2336
2337         Reverted changeset:
2338
2339         "`async` should be able to be used as an imported binding
2340         name"
2341         https://bugs.webkit.org/show_bug.cgi?id=176573
2342         http://trac.webkit.org/changeset/223022
2343
2344 2017-10-09  Robin Morisset  <rmorisset@apple.com>
2345
2346         Make the names of the options consistent
2347         https://bugs.webkit.org/show_bug.cgi?id=177933
2348
2349         Reviewed by Saam Barati.
2350
2351         I added an alias so the old spelling still works.
2352         I also fixed a bunch of typos in comments all around the codebase.
2353
2354         * b3/B3LowerToAir.cpp:
2355         * dfg/DFGByteCodeParser.cpp:
2356         (JSC::DFG::ByteCodeParser::parseBlock):
2357         * dfg/DFGIntegerRangeOptimizationPhase.cpp:
2358         * dfg/DFGOperations.h:
2359         * dfg/DFGSSAConversionPhase.h:
2360         * dfg/DFGSpeculativeJIT.h:
2361         * ftl/FTLLowerDFGToB3.cpp:
2362         (JSC::FTL::DFG::LowerDFGToB3::lower):
2363         * ftl/FTLOSREntry.cpp:
2364         (JSC::FTL::prepareOSREntry):
2365         * jit/CallFrameShuffler.cpp:
2366         (JSC::CallFrameShuffler::prepareForTailCall):
2367         * parser/Nodes.h:
2368         * parser/Parser.cpp:
2369         (JSC::Parser<LexerType>::parseExportDeclaration):
2370         * runtime/Options.h:
2371
2372 2017-10-09  Oleksandr Skachkov  <gskachkov@gmail.com>
2373
2374         Safari 10 /11 problem with if (!await get(something)).
2375         https://bugs.webkit.org/show_bug.cgi?id=176685
2376
2377         Reviewed by Saam Barati.
2378
2379         Using unary operator before `await` lead to count it as identifier.
2380         According to spec https://tc39.github.io/ecma262/#sec-async-function-definitions
2381         and Note 1 `await` is as AwaitExpression and it is allowed to use unary operator
2382
2383         * parser/Parser.cpp:
2384         (JSC::Parser<LexerType>::parsePrimaryExpression):
2385
2386 2017-10-07  Filip Pizlo  <fpizlo@apple.com>
2387
2388         direct-construct-arity-mismatch.js can have GCs that take ~70ms if you force poly proto and disable generational GC
2389         https://bugs.webkit.org/show_bug.cgi?id=178051
2390
2391         Reviewed by Saam Barati.
2392         
2393         After I studied the profile of this test, I found two pathologies in our code relating to
2394         prototypes. I think that now that we support poly proto, it's more likely for these pathologies to
2395         happen. Also, the fact that we force poly proto in some tests, it's possible for one of our tests
2396         to trigger these pathologies.
2397         
2398         - WeakGCMap::m_prototoypes is the set of all prototypes. That's super dangerous. This patch turns
2399           this into a bit in the JSCell header. It uses the last spare bit in indexingTypeAndMisc. Note
2400           that we still have 6 spare bits in cellState, but those are a bit more annoying to get at.
2401         
2402         - WeakGCMap registers itself with GC using a std::function. That means allocating things in the
2403           malloc heap. This changes it to a virtual method on WeakGCMap. I don't know for sure that this is
2404           a problem area, but there are places where we could allocate a lot of WeakGCMaps, like if we have
2405           a lot of transition tables. It's good to reduce the amount of memory those require.
2406         
2407         Also, I saw a FIXME about turning the std::tuple in PrototypeMap into a struct, so I did that while
2408         I was at it. I initially thought that this would have to be part of my solution, but it turned out
2409         not to be. I think it's worth landing anyway since it makes the code a lot more clear.
2410         
2411         This fixes the timeout in that test and probably reduces memory consumption.
2412
2413         * JavaScriptCore.xcodeproj/project.pbxproj:
2414         * dfg/DFGOperations.cpp:
2415         * heap/Heap.cpp:
2416         (JSC::Heap::pruneStaleEntriesFromWeakGCMaps):
2417         (JSC::Heap::registerWeakGCMap):
2418         (JSC::Heap::unregisterWeakGCMap):
2419         * heap/Heap.h:
2420         * inspector/JSInjectedScriptHostPrototype.cpp:
2421         (Inspector::JSInjectedScriptHostPrototype::finishCreation):
2422         * inspector/JSJavaScriptCallFramePrototype.cpp:
2423         (Inspector::JSJavaScriptCallFramePrototype::finishCreation):
2424         * runtime/ArrayIteratorPrototype.cpp:
2425         (JSC::ArrayIteratorPrototype::finishCreation):
2426         * runtime/ArrayPrototype.cpp:
2427         (JSC::ArrayPrototype::finishCreation):
2428         * runtime/AsyncFromSyncIteratorPrototype.cpp:
2429         (JSC::AsyncFromSyncIteratorPrototype::finishCreation):
2430         * runtime/AsyncFunctionPrototype.cpp:
2431         (JSC::AsyncFunctionPrototype::finishCreation):
2432         * runtime/AsyncGeneratorFunctionPrototype.cpp:
2433         (JSC::AsyncGeneratorFunctionPrototype::finishCreation):
2434         * runtime/AsyncGeneratorPrototype.cpp:
2435         (JSC::AsyncGeneratorPrototype::finishCreation):
2436         * runtime/AsyncIteratorPrototype.cpp:
2437         (JSC::AsyncIteratorPrototype::finishCreation):
2438         * runtime/CommonSlowPaths.cpp:
2439         (JSC::SLOW_PATH_DECL):
2440         * runtime/GeneratorFunctionPrototype.cpp:
2441         (JSC::GeneratorFunctionPrototype::finishCreation):
2442         * runtime/GeneratorPrototype.cpp:
2443         (JSC::GeneratorPrototype::finishCreation):
2444         * runtime/IndexingType.h:
2445         * runtime/IteratorPrototype.cpp:
2446         (JSC::IteratorPrototype::finishCreation):
2447         * runtime/JSCInlines.h:
2448         * runtime/JSCell.h:
2449         * runtime/JSCellInlines.h:
2450         (JSC::JSCell::mayBePrototype const):
2451         (JSC::JSCell::didBecomePrototype):
2452         * runtime/JSObject.cpp:
2453         (JSC::JSObject::notifyPresenceOfIndexedAccessors):
2454         (JSC::JSObject::setPrototypeDirect):
2455         * runtime/JSProxy.cpp:
2456         (JSC::JSProxy::setTarget):
2457         * runtime/MapIteratorPrototype.cpp:
2458         (JSC::MapIteratorPrototype::finishCreation):
2459         * runtime/MapPrototype.cpp:
2460         (JSC::MapPrototype::finishCreation):
2461         * runtime/ObjectPrototype.cpp:
2462         (JSC::ObjectPrototype::finishCreation):
2463         * runtime/PrototypeKey.h: Added.
2464         (JSC::PrototypeKey::PrototypeKey):
2465         (JSC::PrototypeKey::prototype const):
2466         (JSC::PrototypeKey::inlineCapacity const):
2467         (JSC::PrototypeKey::classInfo const):
2468         (JSC::PrototypeKey::globalObject const):
2469         (JSC::PrototypeKey::operator== const):
2470         (JSC::PrototypeKey::operator!= const):
2471         (JSC::PrototypeKey::operator bool const):
2472         (JSC::PrototypeKey::isHashTableDeletedValue const):
2473         (JSC::PrototypeKey::hash const):
2474         (JSC::PrototypeKeyHash::hash):
2475         (JSC::PrototypeKeyHash::equal):
2476         * runtime/PrototypeMap.cpp:
2477         (JSC::PrototypeMap::createEmptyStructure):
2478         (JSC::PrototypeMap::clearEmptyObjectStructureForPrototype):
2479         * runtime/PrototypeMap.h:
2480         (JSC::PrototypeMap::PrototypeMap):
2481         * runtime/PrototypeMapInlines.h: Removed.
2482         * runtime/SetIteratorPrototype.cpp:
2483         (JSC::SetIteratorPrototype::finishCreation):
2484         * runtime/SetPrototype.cpp:
2485         (JSC::SetPrototype::finishCreation):
2486         * runtime/StringIteratorPrototype.cpp:
2487         (JSC::StringIteratorPrototype::finishCreation):
2488         * runtime/WeakGCMap.h:
2489         (JSC::WeakGCMapBase::~WeakGCMapBase):
2490         * runtime/WeakGCMapInlines.h:
2491         (JSC::KeyTraitsArg>::WeakGCMap):
2492         * runtime/WeakMapPrototype.cpp:
2493         (JSC::WeakMapPrototype::finishCreation):
2494         * runtime/WeakSetPrototype.cpp:
2495         (JSC::WeakSetPrototype::finishCreation):
2496
2497 2017-10-07  Filip Pizlo  <fpizlo@apple.com>
2498
2499         Octane/splay can leak memory due to stray pointers on the stack when run from the command line
2500         https://bugs.webkit.org/show_bug.cgi?id=178054
2501
2502         Reviewed by Saam Barati.
2503         
2504         This throws in a bunch of sanitize calls. It fixes the problem. It's also performance-neutral. In
2505         most cases, calling the sanitize function is O(1), because it doesn't have anything to do if the stack
2506         height stays relatively constant.
2507
2508         * dfg/DFGOperations.cpp:
2509         * dfg/DFGTierUpCheckInjectionPhase.cpp:
2510         (JSC::DFG::TierUpCheckInjectionPhase::run):
2511         * ftl/FTLOSREntry.cpp:
2512         * heap/Heap.cpp:
2513         (JSC::Heap::runCurrentPhase):
2514         * heap/MarkedAllocatorInlines.h:
2515         (JSC::MarkedAllocator::tryAllocate):
2516         (JSC::MarkedAllocator::allocate):
2517         * heap/Subspace.cpp:
2518         (JSC::Subspace::tryAllocateSlow):
2519         * jit/AssemblyHelpers.h:
2520         (JSC::AssemblyHelpers::sanitizeStackInline):
2521         * jit/ThunkGenerators.cpp:
2522         (JSC::slowPathFor):
2523         * runtime/VM.h:
2524         (JSC::VM::addressOfLastStackTop):
2525
2526 2017-10-07  Yusuke Suzuki  <utatane.tea@gmail.com>
2527
2528         `async` should be able to be used as an imported binding name
2529         https://bugs.webkit.org/show_bug.cgi?id=176573
2530
2531         Reviewed by Darin Adler.
2532
2533         Previously, we have ASYNC keyword in the parser. This is introduced only for performance,
2534         and ECMA262 spec does not categorize "async" to keyword. This makes parser code complicated,
2535         since ASYNC should be handled as IDENT. If we missed this ASYNC keyword, we cause a bug.
2536         For example, import declaration failed to bind imported binding to the name "async" because
2537         the parser considered ASYNC as keyword.
2538
2539         This patch removes ASYNC keyword from the parser. By carefully handling ASYNC, we can keep
2540         the current performance without using this ASYNC keyword.
2541
2542         * parser/Keywords.table:
2543         * parser/Parser.cpp:
2544         (JSC::Parser<LexerType>::parseStatementListItem):
2545         (JSC::Parser<LexerType>::parseStatement):
2546         (JSC::Parser<LexerType>::maybeParseAsyncFunctionDeclarationStatement):
2547         (JSC::Parser<LexerType>::parseClass):
2548         (JSC::Parser<LexerType>::parseExportDeclaration):
2549         (JSC::Parser<LexerType>::parseAssignmentExpression):
2550         (JSC::Parser<LexerType>::parseProperty):
2551         (JSC::Parser<LexerType>::parsePrimaryExpression):
2552         (JSC::Parser<LexerType>::parseMemberExpression):
2553         (JSC::Parser<LexerType>::printUnexpectedTokenText):
2554         * parser/ParserTokens.h:
2555         * runtime/CommonIdentifiers.h:
2556
2557 2017-09-29  Filip Pizlo  <fpizlo@apple.com>
2558
2559         Enable gigacage on iOS
2560         https://bugs.webkit.org/show_bug.cgi?id=177586
2561
2562         Reviewed by JF Bastien.
2563
2564         The hardest part of enabling Gigacage on iOS is that it requires loading global variables while
2565         executing JS, so the LLInt needs to know how to load from global variables on all platforms that
2566         have Gigacage. So, this teaches ARM64 how to load from global variables.
2567         
2568         Also, this makes the code handle disabling the gigacage a bit better.
2569
2570         * ftl/FTLLowerDFGToB3.cpp:
2571         (JSC::FTL::DFG::LowerDFGToB3::caged):
2572         * jit/AssemblyHelpers.h:
2573         (JSC::AssemblyHelpers::cage):
2574         (JSC::AssemblyHelpers::cageConditionally):
2575         * offlineasm/arm64.rb:
2576         * offlineasm/asm.rb:
2577         * offlineasm/instructions.rb:
2578
2579 2017-10-06  Michael Saboff  <msaboff@apple.com>
2580
2581         Enable RegExp JIT for match only Unicode RegExp's
2582         https://bugs.webkit.org/show_bug.cgi?id=178033
2583
2584         Reviewed by JF Bastien.
2585
2586         I forgot to turn on JIT'ing for match-only Unicode RegExp's in r221052.  Do it now.
2587
2588         * runtime/RegExp.cpp:
2589         (JSC::RegExp::compileMatchOnly):
2590
2591 2017-10-06  Alex Christensen  <achristensen@webkit.org>
2592
2593         Build fix after r223002.
2594
2595         * dfg/DFGOSRExit.cpp:
2596         (JSC::DFG::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer):
2597         (JSC::DFG::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
2598
2599 2017-10-06  Commit Queue  <commit-queue@webkit.org>
2600
2601         Unreviewed, rolling out r222791 and r222873.
2602         https://bugs.webkit.org/show_bug.cgi?id=178031
2603
2604         Caused crashes with workers/wasm LayoutTests (Requested by
2605         ryanhaddad on #webkit).
2606
2607         Reverted changesets:
2608
2609         "WebAssembly: no VM / JS version of everything but Instance"
2610         https://bugs.webkit.org/show_bug.cgi?id=177473
2611         http://trac.webkit.org/changeset/222791
2612
2613         "WebAssembly: address no VM / JS follow-ups"
2614         https://bugs.webkit.org/show_bug.cgi?id=177887
2615         http://trac.webkit.org/changeset/222873
2616
2617 2017-10-06  Robin Morisset  <rmorisset@apple.com>
2618
2619         Avoid integer overflow in DFGStrengthReduction.cpp
2620         https://bugs.webkit.org/show_bug.cgi?id=177944
2621
2622         Reviewed by Saam Barati.
2623
2624         The check that we won't do integer overflow by negating INT32_MIN was itself an integer overflow.
2625         I think that signed integer overflow is undefined behaviour in C, so I replace it by an explicit check that value != INT32_MIN instead.
2626
2627         * dfg/DFGStrengthReductionPhase.cpp:
2628         (JSC::DFG::StrengthReductionPhase::handleNode):
2629
2630 2017-10-05  Keith Miller  <keith_miller@apple.com>
2631
2632         JSC generate unified sources doesn't need to run during installhdrs.
2633         https://bugs.webkit.org/show_bug.cgi?id=177640
2634
2635         Reviewed by Dan Bernstein.
2636
2637         generate unified sources doesn't need to have a xcconfig file
2638         since we don't have any feature defines. Also, remove the plist
2639         because there's no plist for this...
2640
2641         * JavaScriptCore.xcodeproj/project.pbxproj:
2642
2643 2017-10-05  Jer Noble  <jer.noble@apple.com>
2644
2645         [Cocoa] Enable ENABLE_ENCRYPTED_MEDIA build-time setting
2646         https://bugs.webkit.org/show_bug.cgi?id=177261
2647
2648         Reviewed by Eric Carlson.
2649
2650         * Configurations/FeatureDefines.xcconfig:
2651
2652 2017-10-05  Ryan Haddad  <ryanhaddad@apple.com>
2653
2654         Unreviewed, rolling out r222929.
2655
2656         Caused assertion failures during LayoutTests.
2657
2658         Reverted changeset:
2659
2660         "Only add prototypes to the PrototypeMap if they're not
2661         already present"
2662         https://bugs.webkit.org/show_bug.cgi?id=177952
2663         http://trac.webkit.org/changeset/222929
2664
2665 2017-10-05  Carlos Alberto Lopez Perez  <clopez@igalia.com>
2666
2667         Generate a compile error if release is built without compiler optimizations
2668         https://bugs.webkit.org/show_bug.cgi?id=177665
2669
2670         Reviewed by Brian Burg.
2671
2672         Pass -DRELEASE_WITHOUT_OPTIMIZATIONS to testair.cpp and testb3.cpp because
2673         this files are compiled with -O0 for build speed reasons after r195639.
2674
2675         * JavaScriptCore.xcodeproj/project.pbxproj:
2676
2677 2017-10-05  Saam Barati  <sbarati@apple.com>
2678
2679         Only add prototypes to the PrototypeMap if they're not already present
2680         https://bugs.webkit.org/show_bug.cgi?id=177952
2681
2682         Reviewed by Michael Saboff and JF Bastien.
2683
2684         With poly proto, we need to call PrototypeMap::add more frequently since we don't
2685         know if the prototype is already in the map or not based solely on Structure.
2686         PrototypeMap::add was calling WeakMap::set unconditionally, which would unconditionally
2687         allocate a Weak handle. Allocating a Weak handle is expensive. It's at least 8x more
2688         expensive than just checking if the prototype is in the map prior to adding it. This
2689         patch makes the change to only add the prototype if it's not already in the map. To
2690         do this, I've added a WeakMap::add API that just forwards into HashMap's add API.
2691         This allows us to both only do a single hash table lookup and also to allocate only
2692         a single Weak handle when necessary.
2693
2694         * runtime/PrototypeMapInlines.h:
2695         (JSC::PrototypeMap::addPrototype):
2696         * runtime/WeakGCMap.h:
2697         (JSC::WeakGCMap::add):
2698
2699 2017-10-05  Saam Barati  <sbarati@apple.com>
2700
2701         Unreviewed. Disable probe OSR exit on 32-bit until it's fixed.
2702
2703         * runtime/Options.cpp:
2704         (JSC::recomputeDependentOptions):
2705
2706 2017-10-05  Saam Barati  <sbarati@apple.com>
2707
2708         Make sure all prototypes under poly proto get added into the VM's prototype map
2709         https://bugs.webkit.org/show_bug.cgi?id=177909
2710
2711         Reviewed by Keith Miller.
2712
2713         This is an invariant of prototypes that I broke when doing poly proto. This patch fixes it.
2714
2715         * JavaScriptCore.xcodeproj/project.pbxproj:
2716         * bytecode/BytecodeList.json:
2717         * dfg/DFGByteCodeParser.cpp:
2718         (JSC::DFG::ByteCodeParser::parseBlock):
2719         * dfg/DFGOperations.cpp:
2720         * runtime/CommonSlowPaths.cpp:
2721         (JSC::SLOW_PATH_DECL):
2722         * runtime/JSCInlines.h:
2723         * runtime/PrototypeMap.cpp:
2724         (JSC::PrototypeMap::addPrototype): Deleted.
2725         * runtime/PrototypeMap.h:
2726         * runtime/PrototypeMapInlines.h:
2727         (JSC::PrototypeMap::isPrototype const):
2728         (JSC::PrototypeMap::addPrototype):
2729
2730 2017-09-30  Yusuke Suzuki  <utatane.tea@gmail.com>
2731
2732         [JSC] Introduce import.meta
2733         https://bugs.webkit.org/show_bug.cgi?id=177703
2734
2735         Reviewed by Filip Pizlo.
2736
2737         This patch adds stage 3 `import.meta`[1].
2738         We add a new hook function moduleLoaderCreateImportMetaProperties, which creates
2739         import meta properties object to this module. And we set this object as @meta
2740         private variable in module environments. So module code can access this by accessing
2741         @meta private variable.
2742
2743         [1]: https://github.com/tc39/proposal-import-meta
2744
2745         * builtins/BuiltinNames.h:
2746         * builtins/ModuleLoaderPrototype.js:
2747         * bytecompiler/BytecodeGenerator.cpp:
2748         (JSC::BytecodeGenerator::BytecodeGenerator):
2749         * jsc.cpp:
2750         (GlobalObject::moduleLoaderCreateImportMetaProperties):
2751         * parser/Parser.cpp:
2752         (JSC::Parser<LexerType>::parseModuleSourceElements):
2753         (JSC::Parser<LexerType>::parseMemberExpression):
2754         * runtime/JSGlobalObject.cpp:
2755         * runtime/JSGlobalObject.h:
2756         * runtime/JSModuleLoader.cpp:
2757         (JSC::JSModuleLoader::createImportMetaProperties):
2758         * runtime/JSModuleLoader.h:
2759         * runtime/JSModuleRecord.cpp:
2760         (JSC::JSModuleRecord::link):
2761         (JSC::JSModuleRecord::instantiateDeclarations):
2762         * runtime/JSModuleRecord.h:
2763         * runtime/ModuleLoaderPrototype.cpp:
2764         (JSC::moduleLoaderPrototypeModuleDeclarationInstantiation):
2765
2766 2017-10-04  Saam Barati  <sbarati@apple.com>
2767
2768         Make pertinent AccessCases watch the poly proto watchpoint
2769         https://bugs.webkit.org/show_bug.cgi?id=177765
2770
2771         Reviewed by Keith Miller.
2772
2773         This patch makes it so that stubs that encounter a structure with a
2774         valid poly proto watchpoint will watch the poly proto watchpoint. This
2775         ensures that if the watchpoint is fired, the stub will be cleared
2776         and have a chance to regenerate. In an ideal world, this will lead
2777         to the stub generating better code since it may never encounter the
2778         non-poly proto structure again.
2779         
2780         This patch also fixes a bug in the original poly proto code where
2781         I accidentally had a condition inverted. The bad code caused a
2782         stub that continually cached two structures which are structurally
2783         equivalent but with different prototype objects to always clear itself.
2784         The code should have been written differently. It should have only
2785         cleared if the poly proto watchpoint *was not* fired. The code
2786         accidentally cleared only if stub *was* fired.
2787
2788         * bytecode/AccessCase.cpp:
2789         (JSC::AccessCase::commit):
2790         * bytecode/PolymorphicAccess.cpp:
2791         (JSC::PolymorphicAccess::addCases):
2792         (WTF::printInternal):
2793         * bytecode/PolymorphicAccess.h:
2794         (JSC::AccessGenerationResult::shouldResetStubAndFireWatchpoints const):
2795         (JSC::AccessGenerationResult::addWatchpointToFire):
2796         (JSC::AccessGenerationResult::fireWatchpoints):
2797         (JSC::AccessGenerationResult::shouldResetStub const): Deleted.
2798         * bytecode/StructureStubInfo.cpp:
2799         (JSC::StructureStubInfo::addAccessCase):
2800         (JSC::StructureStubInfo::reset):
2801         * bytecode/Watchpoint.h:
2802         (JSC::InlineWatchpointSet::inflate):
2803         * jit/Repatch.cpp:
2804         (JSC::fireWatchpointsAndClearStubIfNeeded):
2805         (JSC::tryCacheGetByID):
2806         (JSC::repatchGetByID):
2807         (JSC::tryCachePutByID):
2808         (JSC::repatchPutByID):
2809         (JSC::tryCacheIn):
2810         (JSC::repatchIn):
2811         (JSC::tryRepatchIn): Deleted.
2812
2813 2017-10-04  Matt Baker  <mattbaker@apple.com>
2814
2815         Web Inspector: Improve CanvasManager recording events
2816         https://bugs.webkit.org/show_bug.cgi?id=177762
2817
2818         Reviewed by Devin Rousso.
2819
2820         * inspector/protocol/Canvas.json:
2821         Renamed events for clarity and consistency; made recording data optional.
2822
2823 2017-10-04  JF Bastien  <jfbastien@apple.com>
2824
2825         WTF: Update std::expected to match current proposal
2826         https://bugs.webkit.org/show_bug.cgi?id=177881
2827
2828         Reviewed by Mark Lam.
2829
2830         Update API.
2831
2832         * wasm/WasmB3IRGenerator.cpp:
2833         * wasm/WasmModule.cpp:
2834         (JSC::Wasm::makeValidationResult):
2835         * wasm/WasmParser.h:
2836         * wasm/WasmValidate.cpp:
2837         * wasm/generateWasmValidateInlinesHeader.py:
2838         (loadMacro):
2839         (storeMacro):
2840
2841 2017-10-04  JF Bastien  <jfbastien@apple.com>
2842
2843         WebAssembly: address no VM / JS follow-ups
2844         https://bugs.webkit.org/show_bug.cgi?id=177887
2845
2846         Reviewed by Saam Barati.
2847
2848         All minor fixes, no functional changes.
2849
2850         * wasm/WasmB3IRGenerator.cpp:
2851         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
2852         (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
2853         (JSC::Wasm::B3IRGenerator::addCurrentMemory):
2854         (JSC::Wasm::B3IRGenerator::addCall):
2855         (JSC::Wasm::B3IRGenerator::addCallIndirect):
2856         * wasm/WasmContext.cpp:
2857         (JSC::Wasm::Context::store):
2858         * wasm/WasmMemoryMode.h:
2859         * wasm/WasmTable.h:
2860         * wasm/js/JSWebAssemblyInstance.cpp:
2861         (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
2862         * wasm/js/JSWebAssemblyTable.cpp:
2863         (JSC::JSWebAssemblyTable::JSWebAssemblyTable):
2864         (JSC::JSWebAssemblyTable::grow):
2865
2866 2017-10-04  Mark Lam  <mark.lam@apple.com>
2867
2868         Add support for using Probe DFG OSR Exit behind a runtime flag.
2869         https://bugs.webkit.org/show_bug.cgi?id=177844
2870         <rdar://problem/34801425>
2871
2872         Reviewed by Saam Barati.
2873
2874         This is based on the code originally posted in https://bugs.webkit.org/show_bug.cgi?id=175144
2875         (in r221774 and r221832) with some optimizations and bug fixes added.  The probe
2876         based DFG OSR Exit is only enabled if Options::useProbeOSRExit() is true.  We're
2877         landing this behind an option switch to make it easier to tune performance using
2878         the probe based OSR exit.
2879
2880         * JavaScriptCore.xcodeproj/project.pbxproj:
2881         * assembler/MacroAssembler.cpp:
2882         (JSC::stdFunctionCallback):
2883         * assembler/MacroAssemblerPrinter.cpp:
2884         (JSC::Printer::printCallback):
2885         * assembler/ProbeContext.cpp:
2886         (JSC::Probe::executeProbe):
2887         (JSC::Probe::flushDirtyStackPages):
2888         * assembler/ProbeContext.h:
2889         (JSC::Probe::Context::Context):
2890         (JSC::Probe::Context::arg):
2891         * assembler/ProbeFrame.h: Added.
2892         (JSC::Probe::Frame::Frame):
2893         (JSC::Probe::Frame::argument):
2894         (JSC::Probe::Frame::operand):
2895         (JSC::Probe::Frame::setArgument):
2896         (JSC::Probe::Frame::setOperand):
2897         (JSC::Probe::Frame::get):
2898         (JSC::Probe::Frame::set):
2899         * assembler/ProbeStack.cpp:
2900         (JSC::Probe::Page::lowWatermarkFromVisitingDirtyChunks):
2901         (JSC::Probe::Stack::Stack):
2902         (JSC::Probe::Stack::lowWatermarkFromVisitingDirtyPages):
2903         * assembler/ProbeStack.h:
2904         (JSC::Probe::Stack::Stack):
2905         (JSC::Probe::Stack::lowWatermark):
2906         (JSC::Probe::Stack::set):
2907         (JSC::Probe::Stack::savedStackPointer const):
2908         (JSC::Probe::Stack::setSavedStackPointer):
2909         (JSC::Probe::Stack::newStackPointer const): Deleted.
2910         (JSC::Probe::Stack::setNewStackPointer): Deleted.
2911         * bytecode/ArrayProfile.h:
2912         (JSC::ArrayProfile::observeArrayMode):
2913         * bytecode/CodeBlock.cpp:
2914         (JSC::CodeBlock::updateOSRExitCounterAndCheckIfNeedToReoptimize):
2915         * bytecode/CodeBlock.h:
2916         (JSC::CodeBlock::addressOfOSRExitCounter): Deleted.
2917         * bytecode/ExecutionCounter.h:
2918         (JSC::ExecutionCounter::hasCrossedThreshold const):
2919         (JSC::ExecutionCounter::setNewThresholdForOSRExit):
2920         * bytecode/MethodOfGettingAValueProfile.cpp:
2921         (JSC::MethodOfGettingAValueProfile::reportValue):
2922         * bytecode/MethodOfGettingAValueProfile.h:
2923         * dfg/DFGDriver.cpp:
2924         (JSC::DFG::compileImpl):
2925         * dfg/DFGJITCompiler.cpp:
2926         (JSC::DFG::JITCompiler::linkOSRExits):
2927         (JSC::DFG::JITCompiler::link):
2928         * dfg/DFGOSRExit.cpp:
2929         (JSC::DFG::jsValueFor):
2930         (JSC::DFG::restoreCalleeSavesFor):
2931         (JSC::DFG::saveCalleeSavesFor):
2932         (JSC::DFG::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer):
2933         (JSC::DFG::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
2934         (JSC::DFG::saveOrCopyCalleeSavesFor):
2935         (JSC::DFG::createDirectArgumentsDuringExit):
2936         (JSC::DFG::createClonedArgumentsDuringExit):
2937         (JSC::DFG::emitRestoreArguments):
2938         (JSC::DFG::OSRExit::executeOSRExit):
2939         (JSC::DFG::reifyInlinedCallFrames):
2940         (JSC::DFG::adjustAndJumpToTarget):
2941         (JSC::DFG::printOSRExit):
2942         * dfg/DFGOSRExit.h:
2943         (JSC::DFG::OSRExitState::OSRExitState):
2944         * dfg/DFGThunks.cpp:
2945         (JSC::DFG::osrExitThunkGenerator):
2946         * dfg/DFGThunks.h:
2947         * dfg/DFGVariableEventStream.cpp:
2948         (JSC::DFG::tryToSetConstantRecovery):
2949         (JSC::DFG::VariableEventStream::reconstruct const):
2950         (JSC::DFG::VariableEventStream::tryToSetConstantRecovery const): Deleted.
2951         * dfg/DFGVariableEventStream.h:
2952         * profiler/ProfilerOSRExit.h:
2953         (JSC::Profiler::OSRExit::incCount):
2954         * runtime/JSCJSValue.h:
2955         * runtime/JSCJSValueInlines.h:
2956         * runtime/Options.h:
2957
2958 2017-10-04  Ryan Haddad  <ryanhaddad@apple.com>
2959
2960         Unreviewed, rolling out r222840.
2961
2962         This change breaks internal builds.
2963
2964         Reverted changeset:
2965
2966         "Generate a compile error if release is built without compiler
2967         optimizations"
2968         https://bugs.webkit.org/show_bug.cgi?id=177665
2969         http://trac.webkit.org/changeset/222840
2970
2971 2017-10-04  Carlos Alberto Lopez Perez  <clopez@igalia.com>
2972
2973         Generate a compile error if release is built without compiler optimizations
2974         https://bugs.webkit.org/show_bug.cgi?id=177665
2975
2976         Reviewed by Michael Catanzaro.
2977
2978         Pass -DRELEASE_WITHOUT_OPTIMIZATIONS to testair.cpp and testb3.cpp because
2979         this files are compiled with -O0 for build speed reasons after r195639.
2980
2981         * JavaScriptCore.xcodeproj/project.pbxproj:
2982
2983 2017-10-03  Jon Davis  <jond@apple.com>
2984
2985         Update WebAssembly to "Supported"
2986         https://bugs.webkit.org/show_bug.cgi?id=177831
2987
2988         Reviewed by Alexey Proskuryakov.
2989         
2990         Cleaned up Async Iteration and Object rest/spread to use "In Development" 
2991         instead of "In development". 
2992
2993         * features.json: 
2994
2995 2017-10-03  Saam Barati  <sbarati@apple.com>
2996
2997         Implement polymorphic prototypes
2998         https://bugs.webkit.org/show_bug.cgi?id=176391
2999
3000         Reviewed by Filip Pizlo.
3001
3002         This patch changes JSC's object model with respect to where the prototype
3003         of an object is stored. Previously, it was always stored as
3004         a constant value inside Structure. So an object's structure used to
3005         always tell you what its prototype is. Anytime an object changed
3006         its prototype, it would do a structure transition. This enables
3007         a large class of optimizations: just by doing a structure check,
3008         we know what the prototype is.
3009         
3010         However, this design falls down when you have many objects that
3011         have the same shape, but only differ in what their prototype value
3012         is. This arises in many JS programs. A simple, and probably common, example
3013         is when the program has a constructor inside of a function:
3014         ```
3015         function foo() {
3016             class C {
3017                 constructor() { this.field1 = 42; ...; this.fieldN = 42; }
3018                 method1() { doStuffWith(this.field); }
3019                 method2() { doStuffWith(this.field); }
3020             }
3021             let c = new C;
3022             do things with c;
3023             }
3024         repeatedly call foo() here.
3025         ```
3026         
3027         Before this patch, in the above program, each time `new C` created an
3028         object, it would create an object with a different structure. The
3029         reason for this is that each time foo is called, there is a new
3030         instance of C.prototype. However, each `new C` that was created
3031         with have identical shape sans its prototype value. This would
3032         cause all ICs that used `c` to quickly give up on any form of caching
3033         because they would see too many structures and give up and permanently
3034         divert control flow to the slow path.
3035         
3036         This patch fixes this issue by expanding the notion of where the prototype
3037         of an object is stored. There are now two notions of where the prototype
3038         is stored. A Structure can now be in two modes:
3039         1. Mono proto mode. This is the same mode as we used to have. It means
3040         the structure itself has a constant prototype value.
3041         2. Poly proto mode. This means the structure knows nothing about the
3042         prototype value itself. Objects with this structure store their prototype
3043         in normal object field storage. The structure will tell you the offset of
3044         this prototype inside the object's storage. As of today, we only reserve
3045         inline slots for the prototype field because poly proto only occurs
3046         for JSFinalObject. However, this will be expanded to support out of line
3047         offsets in a future patch when we extend poly proto to work when we inherit
3048         from builtin types like Map and Array.
3049         
3050         In this initial patch, we do poly proto style inline caching whenever
3051         we see an object that is poly proto or if an object in its prototype lookup
3052         chain is poly proto. Poly proto ICs work by verifying the lookup chain
3053         at runtime. This essentially boils down to performing structure checks
3054         up the prototype chain. In a future patch, we're going to extend object
3055         property condition set to work with objects that don't have poly proto bases.
3056         
3057         Initially, accesses that have poly proto access chains will always turn
3058         into GetById/PutById in the DFG. In a future patch, I'm going to teach
3059         the DFG how to inline certain accesses that have poly proto in the access
3060         chain.
3061         
3062         One of most interesting parts about this patch is how we decide when to go
3063         poly proto. This patch uses a profiling based approach. An IC will inform
3064         a watchpoint that it sees an opportunity when two Structure's are structurally
3065         the same, sans the base object's prototype. This means that two structures
3066         have equivalent shapes all the way up the prototype chain. To support fast
3067         structural comparison, we compute a hash for a structure based on the properties
3068         it has. We compute this hash as we add properties to the structure. This
3069         computation is nearly free since we always add UniquedStringImpl*'s which
3070         already have their hashes computed. To compare structural equivalence, we
3071         just compare hash values all the way up the prototype chain. This means we
3072         can get hash conflicts between two structures, but it's extremely rare. First,
3073         it'll be rare for two structures to have the same hash. Secondly, we only
3074         consider structures originating from the same executable.
3075         
3076         How we set up this poly proto watchpoint is crucial to its design. When we create_this
3077         an object originating from some executable, that executable will create a Box<InlineWatchpointSet>.
3078         Each structure that originates from this executable will get a copy of that
3079         Box<InlineWatchpointSet>. As that structure transitions to new structures,
3080         they too will get a copy of that Box<InilneWatchpointSet>. Therefore, when
3081         invalidating an arbitrary structure's poly proto watchpoint, we will know
3082         the next time we create_this from that executable that it had been
3083         invalidated, and that we should create an object with a poly proto
3084         structure. We also use the pointer value of this Box<InlineWatchpointSet>
3085         to determine if two structures originated from the same executable. This
3086         pruning will severely limit the chances of getting a hash conflict in practice.
3087         
3088         This patch is neutral on my MBP on traditional JS benchmarks like Octane/Kraken/Sunspider.
3089         It may be a 1-2% ARES-6 progression.
3090         
3091         This patch is between neutral and a 9x progression on the various tests
3092         I added. Most of the microbenchmarks are progressed by at least 50%.
3093
3094         * JavaScriptCore.xcodeproj/project.pbxproj:
3095         * Sources.txt:
3096         * builtins/BuiltinNames.cpp:
3097         * builtins/BuiltinNames.h:
3098         (JSC::BuiltinNames::BuiltinNames):
3099         (JSC::BuiltinNames::underscoreProtoPrivateName const):
3100         * bytecode/AccessCase.cpp:
3101         (JSC::AccessCase::AccessCase):
3102         (JSC::AccessCase::create):
3103         (JSC::AccessCase::commit):
3104         (JSC::AccessCase::guardedByStructureCheck const):
3105         (JSC::AccessCase::canReplace const):
3106         (JSC::AccessCase::dump const):
3107         (JSC::AccessCase::visitWeak const):
3108         (JSC::AccessCase::propagateTransitions const):
3109         (JSC::AccessCase::generateWithGuard):
3110         (JSC::AccessCase::generateImpl):
3111         * bytecode/AccessCase.h:
3112         (JSC::AccessCase::usesPolyProto const):
3113         (JSC::AccessCase::AccessCase):
3114         * bytecode/CodeBlock.cpp:
3115         (JSC::CodeBlock::finishCreation):
3116         * bytecode/GetByIdStatus.cpp:
3117         (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
3118         * bytecode/GetterSetterAccessCase.cpp:
3119         (JSC::GetterSetterAccessCase::GetterSetterAccessCase):
3120         (JSC::GetterSetterAccessCase::create):
3121         * bytecode/GetterSetterAccessCase.h:
3122         * bytecode/InternalFunctionAllocationProfile.h:
3123         (JSC::InternalFunctionAllocationProfile::createAllocationStructureFromBase):
3124         * bytecode/IntrinsicGetterAccessCase.cpp:
3125         (JSC::IntrinsicGetterAccessCase::IntrinsicGetterAccessCase):
3126         * bytecode/IntrinsicGetterAccessCase.h:
3127         * bytecode/ModuleNamespaceAccessCase.cpp:
3128         (JSC::ModuleNamespaceAccessCase::ModuleNamespaceAccessCase):
3129         * bytecode/ObjectAllocationProfile.cpp: Added.
3130         (JSC::ObjectAllocationProfile::initializeProfile):
3131         (JSC::ObjectAllocationProfile::possibleDefaultPropertyCount):
3132         * bytecode/ObjectAllocationProfile.h:
3133         (JSC::ObjectAllocationProfile::clear):
3134         (JSC::ObjectAllocationProfile::initialize): Deleted.
3135         (JSC::ObjectAllocationProfile::possibleDefaultPropertyCount): Deleted.
3136         * bytecode/ObjectPropertyConditionSet.cpp:
3137         * bytecode/PolyProtoAccessChain.cpp: Added.
3138         (JSC::PolyProtoAccessChain::create):
3139         (JSC::PolyProtoAccessChain::needImpurePropertyWatchpoint const):
3140         (JSC::PolyProtoAccessChain::operator== const):
3141         (JSC::PolyProtoAccessChain::dump const):
3142         * bytecode/PolyProtoAccessChain.h: Added.
3143         (JSC::PolyProtoAccessChain::clone):
3144         (JSC::PolyProtoAccessChain:: const):
3145         (JSC::PolyProtoAccessChain::operator!= const):
3146         (JSC::PolyProtoAccessChain::forEach const):
3147         * bytecode/PolymorphicAccess.cpp:
3148         (JSC::PolymorphicAccess::addCases):
3149         (JSC::PolymorphicAccess::regenerate):
3150         (WTF::printInternal):
3151         * bytecode/PolymorphicAccess.h:
3152         (JSC::AccessGenerationResult::shouldResetStub const):
3153         (JSC::AccessGenerationState::AccessGenerationState):
3154         * bytecode/PropertyCondition.cpp:
3155         (JSC::PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint const):
3156         * bytecode/ProxyableAccessCase.cpp:
3157         (JSC::ProxyableAccessCase::ProxyableAccessCase):
3158         (JSC::ProxyableAccessCase::create):
3159         * bytecode/ProxyableAccessCase.h:
3160         * bytecode/PutByIdStatus.cpp:
3161         (JSC::PutByIdStatus::computeForStubInfo):
3162         * bytecode/StructureStubInfo.cpp:
3163         (JSC::StructureStubInfo::addAccessCase):
3164         * dfg/DFGByteCodeParser.cpp:
3165         (JSC::DFG::ByteCodeParser::load):
3166         (JSC::DFG::ByteCodeParser::parseBlock):
3167         * dfg/DFGGraph.cpp:
3168         (JSC::DFG::Graph::canDoFastSpread):
3169         * dfg/DFGOperations.cpp:
3170         * dfg/DFGSpeculativeJIT.cpp:
3171         (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
3172         (JSC::DFG::SpeculativeJIT::compileInstanceOf):
3173         * dfg/DFGSpeculativeJIT.h:
3174         * dfg/DFGSpeculativeJIT64.cpp:
3175         (JSC::DFG::SpeculativeJIT::compile):
3176         * ftl/FTLLowerDFGToB3.cpp:
3177         (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
3178         * jit/JITOpcodes.cpp:
3179         (JSC::JIT::emit_op_instanceof):
3180         * jit/JITOpcodes32_64.cpp:
3181         (JSC::JIT::emit_op_instanceof):
3182         * jit/Repatch.cpp:
3183         (JSC::tryCacheGetByID):
3184         (JSC::tryCachePutByID):
3185         (JSC::tryRepatchIn):
3186         * jsc.cpp:
3187         (WTF::DOMJITGetterBaseJSObject::DOMJITGetterBaseJSObject):
3188         (WTF::DOMJITGetterBaseJSObject::createStructure):
3189         (WTF::DOMJITGetterBaseJSObject::create):
3190         (WTF::DOMJITGetterBaseJSObject::DOMJITAttribute::DOMJITAttribute):
3191         (WTF::DOMJITGetterBaseJSObject::DOMJITAttribute::slowCall):
3192         (WTF::DOMJITGetterBaseJSObject::DOMJITAttribute::callDOMGetter):
3193         (WTF::DOMJITGetterBaseJSObject::customGetter):
3194         (WTF::DOMJITGetterBaseJSObject::finishCreation):
3195         (GlobalObject::finishCreation):
3196         (functionCreateDOMJITGetterBaseJSObject):
3197         * llint/LLIntSlowPaths.cpp:
3198         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
3199         * runtime/ArrayPrototype.cpp:
3200         (JSC::holesMustForwardToPrototype):
3201         (JSC::fastJoin):
3202         (JSC::arrayProtoFuncReverse):
3203         (JSC::moveElements):
3204         * runtime/ClonedArguments.cpp:
3205         (JSC::ClonedArguments::createEmpty):
3206         (JSC::ClonedArguments::createWithInlineFrame):
3207         (JSC::ClonedArguments::createWithMachineFrame):
3208         (JSC::ClonedArguments::createByCopyingFrom):
3209         * runtime/CommonSlowPaths.cpp:
3210         (JSC::SLOW_PATH_DECL):
3211         * runtime/FunctionExecutable.cpp:
3212         (JSC::FunctionExecutable::visitChildren):
3213         * runtime/FunctionExecutable.h:
3214         * runtime/FunctionRareData.cpp:
3215         (JSC::FunctionRareData::initializeObjectAllocationProfile):
3216         * runtime/FunctionRareData.h:
3217         * runtime/InternalFunction.cpp:
3218         (JSC::InternalFunction::createSubclassStructureSlow):
3219         * runtime/JSArray.cpp:
3220         (JSC::JSArray::fastSlice):
3221         (JSC::JSArray::shiftCountWithArrayStorage):
3222         (JSC::JSArray::shiftCountWithAnyIndexingType):
3223         (JSC::JSArray::isIteratorProtocolFastAndNonObservable):
3224         * runtime/JSArrayInlines.h:
3225         (JSC::JSArray::canFastCopy):
3226         * runtime/JSCJSValue.cpp:
3227         (JSC::JSValue::dumpInContextAssumingStructure const):
3228         * runtime/JSFunction.cpp:
3229         (JSC::JSFunction::prototypeForConstruction):
3230         (JSC::JSFunction::allocateAndInitializeRareData):
3231         (JSC::JSFunction::initializeRareData):
3232         (JSC::JSFunction::getOwnPropertySlot):
3233         * runtime/JSFunction.h:
3234         * runtime/JSMap.cpp:
3235         (JSC::JSMap::isIteratorProtocolFastAndNonObservable):
3236         (JSC::JSMap::canCloneFastAndNonObservable):
3237         * runtime/JSObject.cpp:
3238         (JSC::JSObject::putInlineSlow):
3239         (JSC::JSObject::createInitialIndexedStorage):
3240         (JSC::JSObject::createArrayStorage):
3241         (JSC::JSObject::convertUndecidedToArrayStorage):
3242         (JSC::JSObject::convertInt32ToArrayStorage):
3243         (JSC::JSObject::convertDoubleToArrayStorage):
3244         (JSC::JSObject::convertContiguousToArrayStorage):
3245         (JSC::JSObject::ensureInt32Slow):
3246         (JSC::JSObject::ensureDoubleSlow):
3247         (JSC::JSObject::ensureContiguousSlow):
3248         (JSC::JSObject::ensureArrayStorageSlow):
3249         (JSC::JSObject::setPrototypeDirect):
3250         (JSC::JSObject::ordinaryToPrimitive const):
3251         (JSC::JSObject::putByIndexBeyondVectorLength):
3252         (JSC::JSObject::putDirectIndexSlowOrBeyondVectorLength):
3253         (JSC::JSObject::getEnumerableLength):
3254         (JSC::JSObject::anyObjectInChainMayInterceptIndexedAccesses const):
3255         (JSC::JSObject::prototypeChainMayInterceptStoreTo):
3256         (JSC::JSObject::needsSlowPutIndexing const):
3257         (JSC::JSObject::suggestedArrayStorageTransition const):
3258         * runtime/JSObject.h:
3259         (JSC::JSObject::finishCreation):
3260         (JSC::JSObject::getPrototypeDirect const):
3261         (JSC::JSObject::getPropertySlot):
3262         * runtime/JSObjectInlines.h:
3263         (JSC::JSObject::getPropertySlot):
3264         (JSC::JSObject::getNonIndexPropertySlot):
3265         (JSC::JSObject::putInlineForJSObject):
3266         * runtime/JSPropertyNameEnumerator.h:
3267         (JSC::propertyNameEnumerator):
3268         * runtime/JSSet.cpp:
3269         (JSC::JSSet::isIteratorProtocolFastAndNonObservable):
3270         (JSC::JSSet::canCloneFastAndNonObservable):
3271         * runtime/LazyClassStructure.h:
3272         (JSC::LazyClassStructure::prototypeConcurrently const): Deleted.
3273         * runtime/Operations.cpp:
3274         (JSC::normalizePrototypeChain):
3275         * runtime/Operations.h:
3276         * runtime/Options.h:
3277         * runtime/PrototypeMap.cpp:
3278         (JSC::PrototypeMap::createEmptyStructure):
3279         (JSC::PrototypeMap::emptyStructureForPrototypeFromBaseStructure):
3280         (JSC::PrototypeMap::emptyObjectStructureForPrototype):
3281         (JSC::PrototypeMap::clearEmptyObjectStructureForPrototype):
3282         * runtime/PrototypeMap.h:
3283         * runtime/Structure.cpp:
3284         (JSC::Structure::Structure):
3285         (JSC::Structure::create):
3286         (JSC::Structure::holesMustForwardToPrototype const):
3287         (JSC::Structure::changePrototypeTransition):
3288         (JSC::Structure::isCheapDuringGC):
3289         (JSC::Structure::toStructureShape):
3290         (JSC::Structure::dump const):
3291         (JSC::Structure::canCachePropertyNameEnumerator const):
3292         (JSC::Structure::anyObjectInChainMayInterceptIndexedAccesses const): Deleted.
3293         (JSC::Structure::needsSlowPutIndexing const): Deleted.
3294         (JSC::Structure::suggestedArrayStorageTransition const): Deleted.
3295         (JSC::Structure::prototypeForLookup const): Deleted.
3296         (JSC::Structure::prototypeChainMayInterceptStoreTo): Deleted.
3297         (JSC::Structure::canUseForAllocationsOf): Deleted.
3298         * runtime/Structure.h:
3299         * runtime/StructureChain.h:
3300         * runtime/StructureInlines.h:
3301         (JSC::Structure::create):
3302         (JSC::Structure::storedPrototypeObject const):
3303         (JSC::Structure::storedPrototypeStructure const):
3304         (JSC::Structure::storedPrototype const):
3305         (JSC::prototypeForLookupPrimitiveImpl):