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