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