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