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