499a7b617fc09885c871e6e25c183a3b0e7053f3
[WebKit.git] / Source / JavaScriptCore / ChangeLog
1 2017-06-06  Carlos Garcia Campos  <cgarcia@igalia.com>
2
3         [GTK] Web Process deadlock when closing the remote inspector frontend
4         https://bugs.webkit.org/show_bug.cgi?id=172973
5
6         Reviewed by Žan Doberšek.
7
8         We are taking the remote inspector mutex twice. First close message is received, and receivedCloseMessage()
9         takes the mutex. Then RemoteConnectionToTarget::close() is called that, when connected, calls
10         PageDebuggable::disconnect() that ends up calling RemoteInspector::updateTarget() that also takes the remote
11         inspector mutex. We should release the mutex before calling RemoteConnectionToTarget::close().
12
13         * inspector/remote/glib/RemoteInspectorGlib.cpp:
14         (Inspector::RemoteInspector::receivedCloseMessage):
15
16 2017-06-05  Saam Barati  <sbarati@apple.com>
17
18         Try to fix features.json by adding an ESNext section.
19
20         Unreviewed.
21
22         * features.json:
23
24 2017-06-05  David Kilzer  <ddkilzer@apple.com>
25
26         Follow-up: Update JSC's features.json
27         https://bugs.webkit.org/show_bug.cgi?id=172942
28
29         Rubber-stamped by Jon Davis.
30
31         * features.json: Change "Supported in preview" to
32         "Supported" to try to fix <https://webkit.org/status/>.
33
34 2017-06-05  Saam Barati  <sbarati@apple.com>
35
36         We don't properly parse init_expr when the opcode is an unexpected opcode
37         https://bugs.webkit.org/show_bug.cgi?id=172945
38
39         Reviewed by JF Bastien.
40
41         The bug is a simple typo. It should use the constant
42         `true` instead of `false` when invoking the WASM_PARSER_FAIL_IF
43         macro. This failure is already caught by spec tests that fail
44         on arm64 devices.
45
46         * wasm/WasmModuleParser.cpp:
47
48 2017-06-05  Keith Miller  <keith_miller@apple.com>
49
50         OMG tier up checks should be a patchpoint
51         https://bugs.webkit.org/show_bug.cgi?id=172944
52
53         Reviewed by Saam Barati.
54
55         Tier up checks in BBQ should be done as a patchpoint rather than individual B3 opcodes.
56         In order to reduce code generated out of line in each function. We generate a single stub
57         that pushes all the callee-saves. This looks like a 5-10% compile time speedup.
58
59         * wasm/WasmB3IRGenerator.cpp:
60         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
61         (JSC::Wasm::B3IRGenerator::emitTierUpCheck):
62         (JSC::Wasm::B3IRGenerator::addLoop):
63         * wasm/WasmThunks.cpp:
64         (JSC::Wasm::triggerOMGTierUpThunkGenerator):
65         * wasm/WasmThunks.h:
66
67 2017-06-05  Joseph Pecoraro  <pecoraro@apple.com>
68
69         Remove unused VM members
70         https://bugs.webkit.org/show_bug.cgi?id=172941
71
72         Reviewed by Mark Lam.
73
74         * runtime/HashMapImpl.h:
75         (JSC::HashMapImpl::selectStructure): Deleted.
76         * runtime/VM.cpp:
77         (JSC::VM::VM):
78         * runtime/VM.h:
79
80 2017-06-05  Joseph Pecoraro  <pecoraro@apple.com>
81
82         Web Inspector: Improve ES6 Class instances in Heap Snapshot instances view
83         https://bugs.webkit.org/show_bug.cgi?id=172848
84         <rdar://problem/25709212>
85
86         Reviewed by Saam Barati.
87
88         * heap/HeapSnapshotBuilder.h:
89         * heap/HeapSnapshotBuilder.cpp:
90         Update the snapshot version. Change the node's 0 | 1 internal value
91         to be a 32bit bit flag. This is nice in that it is both compatible
92         with the previous snapshot version and the same size. We can use more
93         flags in the future.
94
95         (JSC::HeapSnapshotBuilder::json):
96         In cases where the classInfo gives us "Object" check for a better
97         class name by checking (o).__proto__.constructor.name. We avoid this
98         check in cases where (o).hasOwnProperty("constructor") which is the
99         case for most Foo.prototype objects. Otherwise this would get the
100         name of the Foo superclass for the Foo.prototype object.
101
102         * runtime/JSObject.cpp:
103         (JSC::JSObject::calculatedClassName):
104         Handle some possible edge cases that were not handled before. Such
105         as a JSObject without a GlobalObject, and an object which doesn't
106         have a default getPrototype. Try to make the code a little clearer.
107
108 2017-06-05  Saam Barati  <sbarati@apple.com>
109
110         Update JSC's features.json
111         https://bugs.webkit.org/show_bug.cgi?id=172942
112
113         Rubber stamped by Mark Lam.
114
115         * features.json:
116
117 2017-06-04  Konstantin Tokarev  <annulen@yandex.ru>
118
119         Fix build of Windows-specific code with ICU 59.1
120         https://bugs.webkit.org/show_bug.cgi?id=172729
121
122         Reviewed by Darin Adler.
123
124         Fix conversions from WTF::String to wchar_t* and vice versa.
125
126         * jsc.cpp:
127         (currentWorkingDirectory):
128         (fetchModuleFromLocalFileSystem):
129         * runtime/DateConversion.cpp:
130         (JSC::formatDateTime):
131
132 2017-06-04  Yusuke Suzuki  <utatane.tea@gmail.com>
133
134         [JSC] Drop unnecessary USE(CF) guard for getenv
135         https://bugs.webkit.org/show_bug.cgi?id=172903
136
137         Reviewed by Sam Weinig.
138
139         getenv is not related to USE(CF) and OS(UNIX). It seems that this
140         ifdef only hits in WinCairo, but WinCairo can use getenv.
141         Moreover, in VM::VM, we already use getenv without any ifdef guard.
142
143         This patch just drops it.
144
145         * runtime/VM.cpp:
146         (JSC::enableAssembler):
147
148 2017-06-04  Yusuke Suzuki  <utatane.tea@gmail.com>
149
150         [JSC] Drop OS(DARWIN) for uintptr_t type conflict
151         https://bugs.webkit.org/show_bug.cgi?id=172904
152
153         Reviewed by Sam Weinig.
154
155         In non-Darwin environment, uintptr_t may have the same type
156         to uint64_t. We avoided the compile error by using OS(DARWIN).
157         But, since it depends on cstdint implementaion rather than OS, it is flaky.
158         Instead, we just use template parameter IntegralType.
159         And we describe the type constraint in a SFINAE manner.
160
161         * dfg/DFGOpInfo.h:
162         (JSC::DFG::OpInfo::OpInfo):
163
164 2017-06-03  Csaba Osztrogonác  <ossy@webkit.org>
165
166         [ARM] Unreviewed buildfix after r217711.
167
168         * assembler/MacroAssemblerARM.h:
169         (JSC::MacroAssemblerARM::xor32):
170
171 2017-06-02  Yusuke Suzuki  <utatane.tea@gmail.com>
172
173         ASSERTION FAILED: "We should only declare a function as a lexically scoped variable in scopes where var declarations aren't allowed. ..." for function redeclaration with async function module export
174         https://bugs.webkit.org/show_bug.cgi?id=168844
175
176         Reviewed by Saam Barati.
177
178         As the same to the exported function declaration, we should set statementDepth = 1 for exported async function declaration.
179
180         * parser/Parser.cpp:
181         (JSC::DepthManager::DepthManager):
182         (JSC::Parser<LexerType>::parseExportDeclaration):
183         * parser/Parser.h:
184         (JSC::Parser::DepthManager::DepthManager): Deleted.
185         (JSC::Parser::DepthManager::~DepthManager): Deleted.
186
187 2017-06-02  Keith Miller  <keith_miller@apple.com>
188
189         Defer installing mach breakpoint handler until watchdog is actually called
190         https://bugs.webkit.org/show_bug.cgi?id=172885
191
192         Reviewed by Saam Barati.
193
194         Eagerly installing the mach breakpoint handler causes issues with Xcode GUI debugging.
195         This hides the issue, so it won't occur as often.
196
197         * runtime/VMTraps.cpp:
198         (JSC::VMTraps::SignalSender::send):
199         (JSC::VMTraps::VMTraps): Deleted.
200         * runtime/VMTraps.h:
201
202 2017-06-02  Filip Pizlo  <fpizlo@apple.com>
203
204         Atomics.load and Atomics.store need to be fully fenced
205         https://bugs.webkit.org/show_bug.cgi?id=172844
206
207         Reviewed by Keith Miller.
208         
209         Implement fully fenced loads and stores in FTL using AtomicXchgAdd(0, ptr) for the load and
210         AtomicXchg(value, ptr) for the store.
211         
212         DFG needed no changes because it implements all atomics using a CAS loop.
213         
214         AtomicsObject.cpp now uses new Atomic<> API for fully fences loads and stores.
215         
216         Prior to this change, we used half fences (acquire/release) for atomic loads and stores. This
217         is not correct according to my current understanding of the SAB memory model, which requires
218         that atomic operations are SC with respect to everything not just other atomics.
219
220         * ftl/FTLLowerDFGToB3.cpp:
221         (JSC::FTL::DFG::LowerDFGToB3::compileAtomicsReadModifyWrite):
222         * ftl/FTLOutput.cpp:
223         (JSC::FTL::Output::atomicWeakCAS):
224         * ftl/FTLOutput.h:
225         * runtime/AtomicsObject.cpp:
226
227 2017-06-02  Ryan Haddad  <ryanhaddad@apple.com>
228
229         Unreviewed, attempt to fix the iOS build after r217711.
230
231         * assembler/MacroAssemblerARM64.h:
232         (JSC::MacroAssemblerARM64::xor32):
233         (JSC::MacroAssemblerARM64::xor64):
234
235 2017-06-01  Filip Pizlo  <fpizlo@apple.com>
236
237         GC should use scrambled free-lists
238         https://bugs.webkit.org/show_bug.cgi?id=172793
239
240         Reviewed by Mark Lam.
241         
242         Previously, our bump'n'pop allocator would use a conventional linked-list for the free-list.
243         The linked-list would be threaded through free memory, as is the usual convention.
244         
245         This scrambles the next pointers of that free-list. It also scrambles the head pointer, because
246         this leads to a more natural fast-path structure and saves one register on ARM64.
247         
248         The secret with which pointers are scrambled is per-allocator. Allocators choose a new secret
249         every time they do a sweep-to-pop.
250         
251         This doesn't change the behavior of the bump part of bump'n'pop, but it does refactor the code
252         quite a bit. Previously, there were four copies of the allocator fast path: two in
253         MarkedAllocatorInlines.h, one in MarkedAllocator.cpp, and one in AssemblyHelpers.h. The JIT one
254         was obviously different-looking, but the other three were almost identical. This moves all of
255         that logic into FreeList. There are now just two copies of the allocator: FreeListInlines.h and
256         AssemblyHelpers.h.
257         
258         This appears to be just as fast as our previously allocator.
259
260         * JavaScriptCore.xcodeproj/project.pbxproj:
261         * heap/FreeList.cpp:
262         (JSC::FreeList::FreeList):
263         (JSC::FreeList::~FreeList):
264         (JSC::FreeList::clear):
265         (JSC::FreeList::initializeList):
266         (JSC::FreeList::initializeBump):
267         (JSC::FreeList::contains):
268         (JSC::FreeList::dump):
269         * heap/FreeList.h:
270         (JSC::FreeList::allocationWillFail):
271         (JSC::FreeList::originalSize):
272         (JSC::FreeList::addressOfList):
273         (JSC::FreeList::offsetOfBlock):
274         (JSC::FreeList::offsetOfList):
275         (JSC::FreeList::offsetOfIndex):
276         (JSC::FreeList::offsetOfPayloadEnd):
277         (JSC::FreeList::offsetOfRemaining):
278         (JSC::FreeList::offsetOfOriginalSize):
279         (JSC::FreeList::FreeList): Deleted.
280         (JSC::FreeList::list): Deleted.
281         (JSC::FreeList::bump): Deleted.
282         (JSC::FreeList::operator==): Deleted.
283         (JSC::FreeList::operator!=): Deleted.
284         (JSC::FreeList::operator bool): Deleted.
285         * heap/FreeListInlines.h: Added.
286         (JSC::FreeList::addFreeCell):
287         (JSC::FreeList::allocate):
288         (JSC::FreeList::forEach):
289         (JSC::FreeList::toOffset):
290         (JSC::FreeList::fromOffset):
291         * heap/IncrementalSweeper.cpp:
292         (JSC::IncrementalSweeper::sweepNextBlock):
293         * heap/MarkedAllocator.cpp:
294         (JSC::MarkedAllocator::MarkedAllocator):
295         (JSC::MarkedAllocator::didConsumeFreeList):
296         (JSC::MarkedAllocator::tryAllocateWithoutCollecting):
297         (JSC::MarkedAllocator::tryAllocateIn):
298         (JSC::MarkedAllocator::allocateSlowCaseImpl):
299         (JSC::MarkedAllocator::stopAllocating):
300         (JSC::MarkedAllocator::prepareForAllocation):
301         (JSC::MarkedAllocator::resumeAllocating):
302         (JSC::MarkedAllocator::sweep):
303         (JSC::MarkedAllocator::setFreeList): Deleted.
304         * heap/MarkedAllocator.h:
305         (JSC::MarkedAllocator::freeList):
306         (JSC::MarkedAllocator::isFreeListedCell): Deleted.
307         * heap/MarkedAllocatorInlines.h:
308         (JSC::MarkedAllocator::isFreeListedCell):
309         (JSC::MarkedAllocator::tryAllocate):
310         (JSC::MarkedAllocator::allocate):
311         * heap/MarkedBlock.cpp:
312         (JSC::MarkedBlock::Handle::stopAllocating):
313         (JSC::MarkedBlock::Handle::lastChanceToFinalize):
314         (JSC::MarkedBlock::Handle::resumeAllocating):
315         (JSC::MarkedBlock::Handle::zap):
316         (JSC::MarkedBlock::Handle::sweep):
317         (JSC::MarkedBlock::Handle::isFreeListedCell):
318         (JSC::MarkedBlock::Handle::forEachFreeCell): Deleted.
319         * heap/MarkedBlock.h:
320         * heap/MarkedBlockInlines.h:
321         (JSC::MarkedBlock::Handle::specializedSweep):
322         (JSC::MarkedBlock::Handle::finishSweepKnowingSubspace):
323         (JSC::MarkedBlock::Handle::isFreeListedCell): Deleted.
324         * heap/Subspace.cpp:
325         (JSC::Subspace::finishSweep):
326         * heap/Subspace.h:
327         * jit/AssemblyHelpers.h:
328         (JSC::AssemblyHelpers::emitAllocateWithNonNullAllocator):
329         * runtime/JSDestructibleObjectSubspace.cpp:
330         (JSC::JSDestructibleObjectSubspace::finishSweep):
331         * runtime/JSDestructibleObjectSubspace.h:
332         * runtime/JSSegmentedVariableObjectSubspace.cpp:
333         (JSC::JSSegmentedVariableObjectSubspace::finishSweep):
334         * runtime/JSSegmentedVariableObjectSubspace.h:
335         * runtime/JSStringSubspace.cpp:
336         (JSC::JSStringSubspace::finishSweep):
337         * runtime/JSStringSubspace.h:
338         * wasm/js/JSWebAssemblyCodeBlockSubspace.cpp:
339         (JSC::JSWebAssemblyCodeBlockSubspace::finishSweep):
340         * wasm/js/JSWebAssemblyCodeBlockSubspace.h:
341
342 2017-06-02  Yusuke Suzuki  <utatane.tea@gmail.com>
343
344         [JSC] Use @globalPrivate for concatSlowPath
345         https://bugs.webkit.org/show_bug.cgi?id=172802
346
347         Reviewed by Darin Adler.
348
349         Use @globalPrivate instead of manually putting it to JSGlobalObject.
350
351         * builtins/ArrayPrototype.js:
352         (concatSlowPath): Deleted.
353         * runtime/JSGlobalObject.cpp:
354         (JSC::JSGlobalObject::init):
355
356 2017-06-01  Andy Estes  <aestes@apple.com>
357
358         REGRESSION (r217626): ENABLE_APPLE_PAY_SESSION_V3 was disabled by mistake
359         https://bugs.webkit.org/show_bug.cgi?id=172828
360
361         Reviewed by Beth Dakin.
362
363         * Configurations/FeatureDefines.xcconfig:
364
365 2017-06-01  Keith Miller  <keith_miller@apple.com>
366
367         Undo rollout in r217638 with bug fix
368         https://bugs.webkit.org/show_bug.cgi?id=172824
369
370         Unreviewed, reland patch with unused set_state code removed.
371
372         * API/tests/ExecutionTimeLimitTest.cpp:
373         (dispatchTermitateCallback):
374         (testExecutionTimeLimit):
375         * runtime/JSLock.cpp:
376         (JSC::JSLock::didAcquireLock):
377         * runtime/Options.cpp:
378         (JSC::overrideDefaults):
379         (JSC::Options::initialize):
380         * runtime/Options.h:
381         * runtime/VMTraps.cpp:
382         (JSC::SignalContext::SignalContext):
383         (JSC::SignalContext::adjustPCToPointToTrappingInstruction):
384         (JSC::installSignalHandler):
385         (JSC::VMTraps::SignalSender::send):
386         * tools/SigillCrashAnalyzer.cpp:
387         (JSC::SignalContext::SignalContext):
388         (JSC::SignalContext::dump):
389         (JSC::installCrashHandler):
390         * wasm/WasmBBQPlan.cpp:
391         (JSC::Wasm::BBQPlan::compileFunctions):
392         * wasm/WasmFaultSignalHandler.cpp:
393         (JSC::Wasm::trapHandler):
394         (JSC::Wasm::enableFastMemory):
395         * wasm/WasmMachineThreads.cpp:
396         (JSC::Wasm::resetInstructionCacheOnAllThreads):
397
398 2017-06-01  Guillaume Emont  <guijemont@igalia.com>
399
400         [JSC][MIPS] SamplingProfiler::timerLoop() sleeps for 4000+ seconds
401         https://bugs.webkit.org/show_bug.cgi?id=172800
402
403         Reviewed by Saam Barati.
404
405         This fixes a static_cast<uint64_t> by making it a cast to int64_t
406         instead, which looks like the original intent. This fixes the
407         sampling-profiler tests in JSTests/stress.
408
409         * runtime/SamplingProfiler.cpp:
410         (JSC::SamplingProfiler::timerLoop):
411
412 2017-06-01  Tomas Popela  <tpopela@redhat.com>, Mark Lam  <mark.lam@apple.com>
413
414         RELEASE_ASSERT_NOT_REACHED() in InferredType::kindForFlags() on Big-Endians
415         https://bugs.webkit.org/show_bug.cgi?id=170945
416
417         Reviewed by Mark Lam.
418
419         Re-define PutByIdFlags as a int32_t enum explicitly because it is
420         stored as an int32_t value in UnlinkedInstruction.  This prevents
421         a bug on 64-bit big endian architectures where the word order is
422         inverted (when we convert the UnlinkedInstruction into a CodeBlock
423         Instruction), resulting in the PutByIdFlags value not being stored in
424         the 32-bit word that the rest of the code expects it to be in.
425
426         * bytecode/PutByIdFlags.h:
427
428 2017-05-31  Yusuke Suzuki  <utatane.tea@gmail.com>
429
430         [JSC] Implement String.prototype.concat in JS builtins
431         https://bugs.webkit.org/show_bug.cgi?id=172798
432
433         Reviewed by Sam Weinig.
434
435         Since we have highly effective + operation for strings,
436         implementing String.prototype.concat in JS simplifies the
437         implementation and improves performance by using speculated
438         types.
439
440         Added microbenchmarks show performance improvement.
441
442         string-concat-long-convert     1063.2787+-12.9101    ^    109.0855+-2.8083        ^ definitely 9.7472x faster
443         string-concat-convert          1111.1366+-12.2363    ^     99.3402+-1.9874        ^ definitely 11.1852x faster
444         string-concat                   131.7377+-3.8359     ^     54.3949+-0.9580        ^ definitely 2.4219x faster
445         string-concat-long               79.4726+-1.9644     ^     64.6301+-1.4941        ^ definitely 1.2297x faster
446
447         * builtins/StringPrototype.js:
448         (globalPrivate.stringConcatSlowPath):
449         (concat):
450         * runtime/StringPrototype.cpp:
451         (JSC::StringPrototype::finishCreation):
452         (JSC::stringProtoFuncConcat): Deleted.
453
454 2017-05-31  Mark Lam  <mark.lam@apple.com>
455
456         Remove overrides of visitChildren() that do not add any functionality.
457         https://bugs.webkit.org/show_bug.cgi?id=172789
458         <rdar://problem/32500865>
459
460         Reviewed by Andreas Kling.
461
462         * bytecode/UnlinkedModuleProgramCodeBlock.cpp:
463         (JSC::UnlinkedModuleProgramCodeBlock::visitChildren): Deleted.
464         * bytecode/UnlinkedModuleProgramCodeBlock.h:
465         * bytecode/UnlinkedProgramCodeBlock.cpp:
466         (JSC::UnlinkedProgramCodeBlock::visitChildren): Deleted.
467         * bytecode/UnlinkedProgramCodeBlock.h:
468         * wasm/js/WebAssemblyFunction.cpp:
469         (JSC::WebAssemblyFunction::visitChildren): Deleted.
470         * wasm/js/WebAssemblyFunction.h:
471         * wasm/js/WebAssemblyInstanceConstructor.cpp:
472         (JSC::WebAssemblyInstanceConstructor::visitChildren): Deleted.
473         * wasm/js/WebAssemblyInstanceConstructor.h:
474         * wasm/js/WebAssemblyMemoryConstructor.cpp:
475         (JSC::WebAssemblyMemoryConstructor::visitChildren): Deleted.
476         * wasm/js/WebAssemblyMemoryConstructor.h:
477         * wasm/js/WebAssemblyModuleConstructor.cpp:
478         (JSC::WebAssemblyModuleConstructor::visitChildren): Deleted.
479         * wasm/js/WebAssemblyModuleConstructor.h:
480         * wasm/js/WebAssemblyTableConstructor.cpp:
481         (JSC::WebAssemblyTableConstructor::visitChildren): Deleted.
482         * wasm/js/WebAssemblyTableConstructor.h:
483
484 2017-05-31  Commit Queue  <commit-queue@webkit.org>
485
486         Unreviewed, rolling out r217611 and r217631.
487         https://bugs.webkit.org/show_bug.cgi?id=172785
488
489         "caused wasm-hashset-many.html to become flaky." (Requested by
490         keith_miller on #webkit).
491
492         Reverted changesets:
493
494         "Reland r216808, underlying lldb bug has been fixed."
495         https://bugs.webkit.org/show_bug.cgi?id=172759
496         http://trac.webkit.org/changeset/217611
497
498         "Use dispatch queues for mach exceptions"
499         https://bugs.webkit.org/show_bug.cgi?id=172775
500         http://trac.webkit.org/changeset/217631
501
502 2017-05-31  Oleksandr Skachkov  <gskachkov@gmail.com>
503
504         Rolling out: Prevent async methods named 'function'
505         https://bugs.webkit.org/show_bug.cgi?id=172776
506
507         Reviewed by Mark Lam.
508
509         Rolling out https://bugs.webkit.org/show_bug.cgi?id=172660 r217578, 
510         https://bugs.webkit.org/show_bug.cgi?id=172598  r217478
511         PR to spec was closed, so changes need to roll out. See
512         https://github.com/tc39/ecma262/pull/884#issuecomment-305212494 
513
514         * parser/Parser.cpp:
515         (JSC::Parser<LexerType>::parseClass):
516         (JSC::Parser<LexerType>::parsePropertyMethod):
517
518 2017-05-31  Andy Estes  <aestes@apple.com>
519
520         Rename ENABLE_APPLE_PAY_DELEGATE to ENABLE_APPLE_PAY_SESSION_V3 and bump the supported version number
521         https://bugs.webkit.org/show_bug.cgi?id=172366
522
523         Reviewed by Daniel Bates.
524
525         * Configurations/FeatureDefines.xcconfig:
526
527 2017-05-31  Keith Miller  <keith_miller@apple.com>
528
529         Reland r216808, underlying lldb bug has been fixed.
530         https://bugs.webkit.org/show_bug.cgi?id=172759
531
532
533         Unreviewed, relanding old patch. See: rdar://problem/31183352
534
535         * API/tests/ExecutionTimeLimitTest.cpp:
536         (dispatchTermitateCallback):
537         (testExecutionTimeLimit):
538         * runtime/JSLock.cpp:
539         (JSC::JSLock::didAcquireLock):
540         * runtime/Options.cpp:
541         (JSC::overrideDefaults):
542         (JSC::Options::initialize):
543         * runtime/Options.h:
544         * runtime/VMTraps.cpp:
545         (JSC::SignalContext::SignalContext):
546         (JSC::SignalContext::adjustPCToPointToTrappingInstruction):
547         (JSC::installSignalHandler):
548         (JSC::VMTraps::SignalSender::send):
549         * tools/SigillCrashAnalyzer.cpp:
550         (JSC::SignalContext::SignalContext):
551         (JSC::SignalContext::dump):
552         (JSC::installCrashHandler):
553         * wasm/WasmBBQPlan.cpp:
554         (JSC::Wasm::BBQPlan::compileFunctions):
555         * wasm/WasmFaultSignalHandler.cpp:
556         (JSC::Wasm::trapHandler):
557         (JSC::Wasm::enableFastMemory):
558         * wasm/WasmMachineThreads.cpp:
559         (JSC::Wasm::resetInstructionCacheOnAllThreads):
560
561 2017-05-31  Keith Miller  <keith_miller@apple.com>
562
563         Fix leak in PromiseDeferredTimer
564         https://bugs.webkit.org/show_bug.cgi?id=172755
565
566         Reviewed by JF Bastien.
567
568         We were not properly freeing the list of dependencies if we were already tracking the promise before.
569         This is because addPendingPromise takes the list of dependencies as an rvalue-reference. In the case
570         where we were already tracking the promise we append the provided dependency list to the existing list.
571         Since we never bound or rvalue-ref to a non-temporary value we never destructed the Vector, leaking its
572         contents.
573
574         * runtime/PromiseDeferredTimer.cpp:
575         (JSC::PromiseDeferredTimer::addPendingPromise):
576
577 2017-05-30  Oleksandr Skachkov  <gskachkov@gmail.com>
578
579         Prevent async methods named 'function' in Object literal
580         https://bugs.webkit.org/show_bug.cgi?id=172660
581
582         Reviewed by Saam Barati.
583
584         Prevent async method named 'function' in object.
585         https://github.com/tc39/ecma262/pull/884
586
587         * parser/Parser.cpp:
588         (JSC::Parser<LexerType>::parsePropertyMethod):
589
590 2017-05-30  Oleksandr Skachkov  <gskachkov@gmail.com>
591
592         ASSERTION FAILED: generator.isConstructor() || generator.derivedContextType() == DerivedContextType::DerivedConstructorContext
593         https://bugs.webkit.org/show_bug.cgi?id=171274
594
595         Reviewed by Saam Barati.
596
597         Current patch allow to use async arrow function within constructor,
598         and allow to access to `this`. Current patch force load 'this' from 
599         virtual scope each time as we access to `this` in async arrow function
600         within constructor it is neccessary because async function can be 
601         suspended and `superCall` can be called and async function resumed. 
602    
603         * bytecompiler/BytecodeGenerator.cpp:
604         (JSC::BytecodeGenerator::emitPutGeneratorFields):
605         (JSC::BytecodeGenerator::ensureThis):
606         * bytecompiler/BytecodeGenerator.h:
607         (JSC::BytecodeGenerator::makeFunction):
608
609 2017-05-30  Ali Juma  <ajuma@chromium.org>
610
611         [CredentialManagement] Incorporate IDL updates from latest spec
612         https://bugs.webkit.org/show_bug.cgi?id=172011
613
614         Reviewed by Daniel Bates.
615
616         * runtime/CommonIdentifiers.h:
617
618 2017-05-30  Alex Christensen  <achristensen@webkit.org>
619
620         Update libwebrtc configuration
621         https://bugs.webkit.org/show_bug.cgi?id=172727
622
623         Reviewed by Geoffrey Garen.
624
625         * Configurations/FeatureDefines.xcconfig:
626
627 2017-05-28  Dan Bernstein  <mitz@apple.com>
628
629         [Xcode] ALWAYS_SEARCH_USER_PATHS is set to YES
630         https://bugs.webkit.org/show_bug.cgi?id=172691
631
632         Reviewed by Tim Horton.
633
634         * Configurations/Base.xcconfig: Set ALWAYS_SEARCH_USER_PATHS to NO.
635         * JavaScriptCore.xcodeproj/project.pbxproj: Added ParseInt.h to the JavaScriptCore target.
636
637 2017-05-28  Yusuke Suzuki  <utatane.tea@gmail.com>
638
639         [JSC] Provide better type information of toLength and tighten bytecode
640         https://bugs.webkit.org/show_bug.cgi?id=172690
641
642         Reviewed by Sam Weinig.
643
644         In this patch, we carefully leverage operator + in order to
645
646         1. tighten bytecode
647
648         operator+ emits to_number bytecode. What this bytecode does is the same
649         to @Number() call. It is more efficient, and it is smaller bytecode
650         than @Number() call (load global variable @Number, set up arguments, and
651         call it).
652
653         2. offer better type prediction data
654
655         Now, we have code like
656
657             length > 0 ? (length < @MAX_SAFE_INTEGER ? length : @MAX_SAFE_INTEGER) : 0
658
659         This is not good because DFG prediction propagation phase predicts as Double
660         since @MAX_SAFE_INTEGER is double. But actually it rarely becomes Double.
661         Usually, the result becomes Int32. This patch leverages to_number in a bit
662         interesting way: to_number has value profiling to offer better type prediction.
663         This value profiling can offer a chance to change the prediction to Int32 efficiently.
664         It is a bit tricky. But it is worth doing to speed up our builtin functions,
665         which should leverage all the JSC's tricky things to be optimized.
666
667         Related microbenchmarks show performance improvement.
668
669                                                   baseline                  patched
670
671             array-prototype-forEach           50.2348+-2.2331           49.7568+-2.3507
672             array-prototype-map               51.0574+-1.8166           47.9531+-2.1653          might be 1.0647x faster
673             array-prototype-some              52.3926+-1.8882     ^     48.3632+-2.0852        ^ definitely 1.0833x faster
674             array-prototype-every             52.7394+-2.0712           50.2896+-2.1480          might be 1.0487x faster
675             array-prototype-reduce            54.9994+-2.3638           51.8716+-2.6253          might be 1.0603x faster
676             array-prototype-reduceRight      209.7594+-9.2594     ^     51.5867+-2.5745        ^ definitely 4.0662x faster
677
678
679         * builtins/GlobalOperations.js:
680         (globalPrivate.toInteger):
681         (globalPrivate.toLength):
682
683 2017-05-28  Sam Weinig  <sam@webkit.org>
684
685         [WebIDL] @@iterator should only be accessed once when disambiguating a union type
686         https://bugs.webkit.org/show_bug.cgi?id=172684
687
688         Reviewed by Yusuke Suzuki.
689
690         * runtime/IteratorOperations.cpp:
691         (JSC::iteratorMethod):
692         (JSC::iteratorForIterable):
693         * runtime/IteratorOperations.h:
694         (JSC::forEachInIterable):
695         Add additional iterator helpers to allow union + sequence conversion code
696         to check for iterability by getting the iterator method, and iterate using
697         that method later on.
698
699 2017-05-28  Yusuke Suzuki  <utatane.tea@gmail.com>
700
701         Unreviewed, build fix for Windows
702         https://bugs.webkit.org/show_bug.cgi?id=172413
703
704         Optimized jsDynamicCast for JSMap and JSSet will be handled in [1].
705
706         [1]: https://bugs.webkit.org/show_bug.cgi?id=172685
707
708         * runtime/JSMap.h:
709         (JSC::isJSMap):
710         (JSC::jsDynamicCast): Deleted.
711         (JSC::>): Deleted.
712         * runtime/JSSet.h:
713         (JSC::isJSSet):
714         (JSC::jsDynamicCast): Deleted.
715         (JSC::>): Deleted.
716         * runtime/MapConstructor.cpp:
717         (JSC::constructMap):
718         * runtime/SetConstructor.cpp:
719         (JSC::constructSet):
720
721 2017-05-28  Mark Lam  <mark.lam@apple.com>
722
723         Implement a faster Interpreter::getOpcodeID().
724         https://bugs.webkit.org/show_bug.cgi?id=172669
725
726         Reviewed by Saam Barati.
727
728         We can implement Interpreter::getOpcodeID() without a hash table lookup by always
729         embedding the OpcodeID in the 32-bit word just before the start of the LLInt
730         handler code that executes each opcode.  getOpcodeID() can therefore just read
731         the 32-bits before the opcode address to get its OpcodeID.
732
733         This is currently only enabled for CPU(X86), CPU(X86_64), CPU(ARM64),
734         CPU(ARM_THUMB2), and only for OS(DARWIN).  It'll probably just work for linux as
735         well, but I'll let the Linux folks turn that on after they have verified that it
736         works on linux too.
737
738         I'll also take this opportunity to clean up how we initialize the opcodeIDTable:
739         1. we only need to initialize it once per process, not once per VM / interpreter
740            instance.
741         2. we can initialize it in the Interpreter constructor instead of requiring a
742            separate call to an initialize() function.
743
744         On debug builds, the Interpreter constructor will also verify that getOpcodeID()
745         is working correctly for each opcode when USE(LLINT_EMBEDDED_OPCODE_ID).
746
747         * bytecode/BytecodeList.json:
748         * generate-bytecode-files:
749         * interpreter/Interpreter.cpp:
750         (JSC::Interpreter::Interpreter):
751         (JSC::Interpreter::opcodeIDTable):
752         (JSC::Interpreter::initialize): Deleted.
753         * interpreter/Interpreter.h:
754         (JSC::Interpreter::getOpcode):
755         (JSC::Interpreter::getOpcodeID):
756         * llint/LowLevelInterpreter.cpp:
757         * runtime/VM.cpp:
758         (JSC::VM::VM):
759
760 2017-05-27  Yusuke Suzuki  <utatane.tea@gmail.com>
761
762         [JSC] Map and Set constructors should have fast path for cloning
763         https://bugs.webkit.org/show_bug.cgi?id=172413
764
765         Reviewed by Saam Barati.
766
767         In this patch, we add a fast path for cloning in Set and Map constructors.
768
769         In ARES-6 Air, we have code like `new Set(set)` to clone the given set.
770         At that time, our generic path just iterates the given set object and add
771         it to the newly created one. It is quite slow because we need to follow
772         the iterator protocol inside C++ and we need to call set.add() repeatedly
773         while the given set guarantees the elements are unique.
774
775         This patch implements clone() function to JSMap and JSSet. Cloning JSMap
776         and JSSet are done really fast without invoking any observable JS functions.
777         To check whether we can use this clone() function in Set and Map constructors,
778         we set several watchpoints.
779
780         In the case of Set,
781
782         1. Set.prototype[Symbol.iterator] is not changed.
783         2. SetIterator.prototype.next is not changed.
784         3. Set.prototype.add is not changed.
785         4. The given Set does not have [Symbol.iterator] function in its instance.
786         5. The given Set's [[Prototype]] is Set.prototype.
787         6. Newly created set's [[Prototype]] is Set.prototype.
788
789         If the above requirements are met, cloning the given Set is not observable to users.
790         Thus we can take a fast path.
791
792         Currently, we do not integrate this optimization into DFG and FTL.
793         And we do not optimize other iterables. For example, we can optimize Set
794         constructor taking Int32 Array. And we should optimize generic iterator cases too.
795         They are planned as part of a separate bug[1].
796
797         This change improves ARES-6 Air by 5.3% in steady state.
798
799         Baseline:
800             Running... Air ( 1  to go)
801             firstIteration:     76.41 +- 15.60 ms
802             averageWorstCase:   40.63 +- 7.54 ms
803             steadyState:        9.13 +- 0.51 ms
804
805
806         Patched:
807             Running... Air ( 1  to go)
808             firstIteration:     75.00 +- 22.54 ms
809             averageWorstCase:   39.18 +- 8.45 ms
810             steadyState:        8.67 +- 0.28 ms
811
812         [1]: https://bugs.webkit.org/show_bug.cgi?id=172419
813
814         * CMakeLists.txt:
815         * JavaScriptCore.xcodeproj/project.pbxproj:
816         * runtime/ArrayIteratorAdaptiveWatchpoint.cpp: Removed.
817         * runtime/HashMapImpl.h:
818         (JSC::HashMapBucket::extractValue):
819         (JSC::HashMapImpl::finishCreation):
820         (JSC::HashMapImpl::add):
821         (JSC::HashMapImpl::setUpHeadAndTail):
822         (JSC::HashMapImpl::addNormalizedNonExistingForCloning):
823         (JSC::HashMapImpl::addNormalizedInternal):
824         * runtime/InternalFunction.cpp:
825         (JSC::InternalFunction::createSubclassStructureSlow):
826         (JSC::InternalFunction::createSubclassStructure): Deleted.
827         * runtime/InternalFunction.h:
828         (JSC::InternalFunction::createSubclassStructure):
829         * runtime/JSGlobalObject.cpp:
830         (JSC::JSGlobalObject::JSGlobalObject):
831         (JSC::JSGlobalObject::init):
832         (JSC::JSGlobalObject::visitChildren):
833         * runtime/JSGlobalObject.h:
834         (JSC::JSGlobalObject::mapIteratorProtocolWatchpoint):
835         (JSC::JSGlobalObject::setIteratorProtocolWatchpoint):
836         (JSC::JSGlobalObject::mapSetWatchpoint):
837         (JSC::JSGlobalObject::setAddWatchpoint):
838         (JSC::JSGlobalObject::mapPrototype):
839         (JSC::JSGlobalObject::jsSetPrototype):
840         (JSC::JSGlobalObject::setStructure):
841         * runtime/JSGlobalObjectInlines.h:
842         (JSC::JSGlobalObject::isMapPrototypeIteratorProtocolFastAndNonObservable):
843         (JSC::JSGlobalObject::isSetPrototypeIteratorProtocolFastAndNonObservable):
844         (JSC::JSGlobalObject::isMapPrototypeSetFastAndNonObservable):
845         (JSC::JSGlobalObject::isSetPrototypeAddFastAndNonObservable):
846         * runtime/JSMap.cpp:
847         (JSC::JSMap::clone):
848         (JSC::JSMap::canCloneFastAndNonObservable):
849         * runtime/JSMap.h:
850         (JSC::jsDynamicCast):
851         (JSC::>):
852         (JSC::JSMap::createStructure): Deleted.
853         (JSC::JSMap::create): Deleted.
854         (JSC::JSMap::set): Deleted.
855         (JSC::JSMap::JSMap): Deleted.
856         * runtime/JSSet.cpp:
857         (JSC::JSSet::clone):
858         (JSC::JSSet::canCloneFastAndNonObservable):
859         * runtime/JSSet.h:
860         (JSC::jsDynamicCast):
861         (JSC::>):
862         (JSC::JSSet::createStructure): Deleted.
863         (JSC::JSSet::create): Deleted.
864         (JSC::JSSet::JSSet): Deleted.
865         * runtime/MapConstructor.cpp:
866         (JSC::constructMap):
867         * runtime/ObjectPropertyChangeAdaptiveWatchpoint.h: Renamed from Source/JavaScriptCore/runtime/ArrayIteratorAdaptiveWatchpoint.h.
868         (JSC::ObjectPropertyChangeAdaptiveWatchpoint::ObjectPropertyChangeAdaptiveWatchpoint):
869         * runtime/SetConstructor.cpp:
870         (JSC::constructSet):
871
872 2017-05-27  Yusuke Suzuki  <utatane.tea@gmail.com>
873
874         [DOMJIT] Move DOMJIT patchpoint infrastructure out of domjit
875         https://bugs.webkit.org/show_bug.cgi?id=172260
876
877         Reviewed by Filip Pizlo.
878
879         DOMJIT::Patchpoint is now used for generalized CheckSubClass. And it becomes mature enough
880         to be used as a general-purpose injectable compiler over all the JIT tiers.
881
882         We extract DOMJIT::Patchpoint to jit/ and rename it JSC::Snippet.
883
884         * CMakeLists.txt:
885         * JavaScriptCore.xcodeproj/project.pbxproj:
886         * bytecode/AccessCaseSnippetParams.cpp: Renamed from Source/JavaScriptCore/bytecode/DOMJITAccessCasePatchpointParams.cpp.
887         (JSC::SlowPathCallGeneratorWithArguments::generateImpl):
888         (JSC::AccessCaseSnippetParams::emitSlowPathCalls):
889         * bytecode/AccessCaseSnippetParams.h: Renamed from Source/JavaScriptCore/bytecode/DOMJITAccessCasePatchpointParams.h.
890         (JSC::AccessCaseSnippetParams::AccessCaseSnippetParams):
891         * bytecode/GetterSetterAccessCase.cpp:
892         (JSC::GetterSetterAccessCase::emitDOMJITGetter):
893         * dfg/DFGAbstractInterpreterInlines.h:
894         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
895         * dfg/DFGByteCodeParser.cpp:
896         (JSC::DFG::blessCallDOMGetter):
897         (JSC::DFG::ByteCodeParser::handleDOMJITGetter):
898         * dfg/DFGClobberize.h:
899         (JSC::DFG::clobberize):
900         * dfg/DFGFixupPhase.cpp:
901         (JSC::DFG::FixupPhase::fixupNode):
902         * dfg/DFGGraph.h:
903         * dfg/DFGNode.h:
904         * dfg/DFGSnippetParams.cpp: Renamed from Source/JavaScriptCore/dfg/DFGDOMJITPatchpointParams.cpp.
905         * dfg/DFGSnippetParams.h: Renamed from Source/JavaScriptCore/dfg/DFGDOMJITPatchpointParams.h.
906         (JSC::DFG::SnippetParams::SnippetParams):
907         * dfg/DFGSpeculativeJIT.cpp:
908         (JSC::DFG::allocateTemporaryRegistersForSnippet):
909         (JSC::DFG::SpeculativeJIT::compileCallDOMGetter):
910         (JSC::DFG::SpeculativeJIT::compileCheckSubClass):
911         (JSC::DFG::allocateTemporaryRegistersForPatchpoint): Deleted.
912         * domjit/DOMJITCallDOMGetterSnippet.h: Renamed from Source/JavaScriptCore/domjit/DOMJITCallDOMGetterPatchpoint.h.
913         (JSC::DOMJIT::CallDOMGetterSnippet::create):
914         * domjit/DOMJITGetterSetter.h:
915         * domjit/DOMJITSignature.h:
916         * domjit/DOMJITValue.h: Removed.
917         * ftl/FTLLowerDFGToB3.cpp:
918         (JSC::FTL::DFG::LowerDFGToB3::compileCheckSubClass):
919         (JSC::FTL::DFG::LowerDFGToB3::compileCallDOMGetter):
920         * ftl/FTLSnippetParams.cpp: Renamed from Source/JavaScriptCore/ftl/FTLDOMJITPatchpointParams.cpp.
921         * ftl/FTLSnippetParams.h: Renamed from Source/JavaScriptCore/ftl/FTLDOMJITPatchpointParams.h.
922         (JSC::FTL::SnippetParams::SnippetParams):
923         * jit/Snippet.h: Renamed from Source/JavaScriptCore/domjit/DOMJITPatchpoint.h.
924         (JSC::Snippet::create):
925         (JSC::Snippet::setGenerator):
926         (JSC::Snippet::generator):
927         * jit/SnippetParams.h: Renamed from Source/JavaScriptCore/domjit/DOMJITPatchpointParams.h.
928         (JSC::SnippetParams::~SnippetParams):
929         (JSC::SnippetParams::Value::Value):
930         (JSC::SnippetParams::Value::isGPR):
931         (JSC::SnippetParams::Value::isFPR):
932         (JSC::SnippetParams::Value::isJSValueRegs):
933         (JSC::SnippetParams::Value::gpr):
934         (JSC::SnippetParams::Value::fpr):
935         (JSC::SnippetParams::Value::jsValueRegs):
936         (JSC::SnippetParams::Value::reg):
937         (JSC::SnippetParams::Value::value):
938         (JSC::SnippetParams::SnippetParams):
939         * jit/SnippetReg.h: Renamed from Source/JavaScriptCore/domjit/DOMJITReg.h.
940         (JSC::SnippetReg::SnippetReg):
941         * jit/SnippetSlowPathCalls.h: Renamed from Source/JavaScriptCore/domjit/DOMJITSlowPathCalls.h.
942         * jsc.cpp:
943         (WTF::DOMJITNode::checkSubClassSnippet):
944         (WTF::DOMJITFunctionObject::checkSubClassSnippet):
945         (WTF::DOMJITNode::checkSubClassPatchpoint): Deleted.
946         (WTF::DOMJITFunctionObject::checkSubClassPatchpoint): Deleted.
947         * runtime/ClassInfo.h:
948
949 2017-05-26  Keith Miller  <keith_miller@apple.com>
950
951         REEGRESSION(r217459): testapi fails in JSExportTest's wrapperForNSObjectisObject().
952         https://bugs.webkit.org/show_bug.cgi?id=172654
953
954         Reviewed by Mark Lam.
955
956         The test's intent is to assert that an exception has not been
957         thrown (as indicated by the message string), but the test was
958         erroneously checking for ! the right condition. This is now fixed.
959
960         * API/tests/JSExportTests.mm:
961         (wrapperForNSObjectisObject):
962
963 2017-05-26  Joseph Pecoraro  <pecoraro@apple.com>
964
965         JSContext Inspector: Improve the reliability of automatically pausing in auto-attach
966         https://bugs.webkit.org/show_bug.cgi?id=172664
967         <rdar://problem/32362933>
968
969         Reviewed by Matt Baker.
970
971         Automatically pause on connection was triggering a pause before the
972         frontend may have initialized. Often during frontend initialization
973         the frontend may perform an action that clears the pause state requested
974         by the developer. This change defers the pause until after the frontend
975         has initialized, right before returning to the application's code.
976
977         * inspector/remote/RemoteControllableTarget.h:
978         * inspector/remote/RemoteInspectionTarget.h:
979         * inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm:
980         (Inspector::RemoteConnectionToTarget::setup):
981         * inspector/remote/glib/RemoteConnectionToTargetGlib.cpp:
982         (Inspector::RemoteConnectionToTarget::setup):
983         * runtime/JSGlobalObjectDebuggable.cpp:
984         (JSC::JSGlobalObjectDebuggable::connect):
985         (JSC::JSGlobalObjectDebuggable::pause): Deleted.
986         * runtime/JSGlobalObjectDebuggable.h:
987         Pass an immediatelyPause boolean on to the controller. Remove
988         the current path that invokes a pause before initialization.
989
990         * inspector/JSGlobalObjectInspectorController.h:
991         * inspector/JSGlobalObjectInspectorController.cpp:
992         (Inspector::JSGlobalObjectInspectorController::connectFrontend):
993         (Inspector::JSGlobalObjectInspectorController::disconnectFrontend):
994         Manage should immediately pause state.
995
996         (Inspector::JSGlobalObjectInspectorController::frontendInitialized):
997         (Inspector::JSGlobalObjectInspectorController::pause): Deleted.
998         When initialized, trigger a pause if requested.
999
1000 2017-05-26  Mark Lam  <mark.lam@apple.com>
1001
1002         Temporarily commenting out a JSExportTest test until webkit.org/b/172654 is fixed.
1003         https://bugs.webkit.org/show_bug.cgi?id=172655
1004
1005         Reviewed by Saam Barati.
1006
1007         * API/tests/JSExportTests.mm:
1008         (wrapperForNSObjectisObject):
1009
1010 2017-05-26  Mark Lam  <mark.lam@apple.com>
1011
1012         REGRESSION(216914): testCFStrings encounters an invalid ExecState callee pointer.
1013         https://bugs.webkit.org/show_bug.cgi?id=172651
1014
1015         Reviewed by Saam Barati.
1016
1017         This is because the assertion utility functions used in testCFStrings() expects
1018         to get the JSGlobalContextRef from the global context variable.  However,
1019         testCFStrings() creates its own JSGlobalContextRef but does not set the global
1020         context variable to it.
1021
1022         The fix is to make testCFStrings() initialize the global context variable properly.
1023
1024         * API/tests/testapi.c:
1025         (testCFStrings):
1026
1027 2017-05-26  Yusuke Suzuki  <utatane.tea@gmail.com>
1028
1029         Give ModuleProgram the same treatment that we did for ProgramCode in bug#167725
1030         https://bugs.webkit.org/show_bug.cgi?id=167805
1031
1032         Reviewed by Saam Barati.
1033
1034         Since ModuleProgramExecutable is executed only once, we can skip compiling
1035         code unreachable from the current program count. This can skip massive
1036         initialization code.
1037
1038         We already do this for global code in bug#167725. This patch extends it to
1039         module code.
1040
1041         * interpreter/Interpreter.cpp:
1042         (JSC::Interpreter::executeModuleProgram):
1043         * interpreter/Interpreter.h:
1044         * jit/JIT.cpp:
1045         (JSC::JIT::privateCompileMainPass):
1046         * runtime/JSModuleRecord.cpp:
1047         (JSC::JSModuleRecord::evaluate):
1048         * runtime/JSModuleRecord.h:
1049         (JSC::JSModuleRecord::moduleProgramExecutable): Deleted.
1050
1051 2017-05-26  Oleksandr Skachkov  <gskachkov@gmail.com>
1052
1053         Prevent async methods named 'function'
1054         https://bugs.webkit.org/show_bug.cgi?id=172598
1055
1056         Reviewed by Mark Lam.
1057
1058         Prevent async method named 'function' in class.
1059         Link to change in ecma262 specification
1060         https://github.com/tc39/ecma262/pull/884
1061
1062         * parser/Parser.cpp:
1063         (JSC::Parser<LexerType>::parseClass):
1064
1065 2017-05-25  Yusuke Suzuki  <utatane.tea@gmail.com>
1066
1067         Unreviewed, build fix for GCC
1068
1069         std::tuple does not have implicit constructor.
1070         Thus, we cannot use implicit construction with initializer brace.
1071         We should specify the name like `GetInst { }`.
1072
1073         * bytecompiler/BytecodeGenerator.h:
1074         (JSC::StructureForInContext::addGetInst):
1075
1076 2017-05-25  Keith Miller  <keith_miller@apple.com>
1077
1078         Cleanup tests after r217240
1079         https://bugs.webkit.org/show_bug.cgi?id=172466
1080
1081         Reviewed by Mark Lam.
1082
1083         I forgot to make my test an actual test. Also, remove second call runJSExportTests()
1084
1085         * API/tests/JSExportTests.mm:
1086         (wrapperForNSObjectisObject):
1087         * API/tests/testapi.mm:
1088         (testObjectiveCAPIMain):
1089
1090 2017-05-25  Michael Saboff  <msaboff@apple.com>
1091
1092         The default setting of Option::criticalGCMemoryThreshold is too high for iOS
1093         https://bugs.webkit.org/show_bug.cgi?id=172617
1094
1095         Reviewed by Mark Lam.
1096
1097         Reducing criticalGCMemoryThreshold to 0.80 eliminated jetsam on iOS devices
1098         when tested running JetStream.
1099
1100         * runtime/Options.h:
1101
1102 2017-05-25  Saam Barati  <sbarati@apple.com>
1103
1104         Our for-in optimization in the bytecode generator does its static analysis incorrectly
1105         https://bugs.webkit.org/show_bug.cgi?id=172532
1106         <rdar://problem/32369452>
1107
1108         Reviewed by Mark Lam.
1109
1110         Our static analysis for when a for-in induction variable
1111         is written to tried to its analysis as we generate
1112         bytecode. This has issues, since it does not account for
1113         the dynamic execution path of the program. Let's consider
1114         a program where our old analysis worked:
1115         
1116         ```
1117         for (let p in o) {
1118             o[p]; // We can transform this into a fast get_direct_pname
1119             p = 20;
1120             o[p]; // We cannot transform this since p has been changed.
1121         }
1122         ```
1123         
1124         However, our static analysis did not account for loops, which exist
1125         in JavaScript. e.g, it would incorrectly compile this program as:
1126         ```
1127         for (let p in o) {
1128             for (let i = 0; i < 20; ++i) {
1129                 o[p]; // It transforms this to use get_direct_pname even though p will be over-written if we get here from the inner loop back edge!
1130                 p = 20;
1131                 o[p]; // We correctly do not transform this.
1132             } 
1133         }
1134         ```
1135         
1136         Because of this flaw, I've made the optimization more conservative.
1137         We now optimistically emit code for the optimized access. However,
1138         if a for-in context is *ever* invalidated, before we pop it off
1139         the stack, we rewrite the program's optimized accesses to no longer
1140         be optimized. To do this, each context keeps track of its optimized
1141         accesses.
1142         
1143         This patch also adds a new bytecode, op_nop, which is just a no-op.
1144         It was helpful to add this because reverting get_direct_pname to get_by_val
1145         will leave us with an extra instruction word because get_direct_pname is
1146         has a length of 7 where get_by_val has a length of 6. This leaves us with
1147         an extra slot that we fill with an op_nop.
1148
1149         * bytecode/BytecodeDumper.cpp:
1150         (JSC::BytecodeDumper<Block>::dumpBytecode):
1151         * bytecode/BytecodeList.json:
1152         * bytecode/BytecodeUseDef.h:
1153         (JSC::computeUsesForBytecodeOffset):
1154         (JSC::computeDefsForBytecodeOffset):
1155         * bytecompiler/BytecodeGenerator.cpp:
1156         (JSC::BytecodeGenerator::emitGetByVal):
1157         (JSC::BytecodeGenerator::popIndexedForInScope):
1158         (JSC::BytecodeGenerator::popStructureForInScope):
1159         (JSC::BytecodeGenerator::invalidateForInContextForLocal):
1160         (JSC::StructureForInContext::pop):
1161         (JSC::IndexedForInContext::pop):
1162         * bytecompiler/BytecodeGenerator.h:
1163         (JSC::StructureForInContext::addGetInst):
1164         (JSC::IndexedForInContext::addGetInst):
1165         * dfg/DFGByteCodeParser.cpp:
1166         (JSC::DFG::ByteCodeParser::parseBlock):
1167         * dfg/DFGCapabilities.cpp:
1168         (JSC::DFG::capabilityLevel):
1169         * jit/JIT.cpp:
1170         (JSC::JIT::privateCompileMainPass):
1171         * jit/JIT.h:
1172         * jit/JITOpcodes.cpp:
1173         (JSC::JIT::emit_op_nop):
1174         * llint/LowLevelInterpreter.asm:
1175
1176 2017-05-25  Mark Lam  <mark.lam@apple.com>
1177
1178         ObjectToStringAdaptiveInferredPropertyValueWatchpoint should not reinstall itself nor handleFire if it's dying shortly.
1179         https://bugs.webkit.org/show_bug.cgi?id=172548
1180         <rdar://problem/31458393>
1181
1182         Reviewed by Filip Pizlo.
1183
1184         Consider the following scenario:
1185
1186         1. A ObjectToStringAdaptiveInferredPropertyValueWatchpoint O1, watches for
1187            structure transitions, e.g. structure S2 transitioning to structure S3.
1188            In this case, O1 would be installed in S2's watchpoint set.
1189         2. When the structure transition happens, structure S2 will fire watchpoint O1.
1190         3. O1's handler will normally re-install itself in the watchpoint set of the new
1191            "transitioned to" structure S3.
1192         4. "Installation" here requires writing into the StructureRareData SD3 of the new
1193            structure S3.  If SD3 does not exist yet, the installation process will trigger
1194            the allocation of StructureRareData SD3.
1195         5. It is possible that the Structure S1, and StructureRareData SD1 that owns the
1196            ObjectToStringAdaptiveInferredPropertyValueWatchpoint O1 is no longer reachable
1197            by the GC, and therefore will be collected soon.
1198         6. The allocation of SD3 in (4) may trigger the sweeping of the StructureRareData
1199            SD1.  This, in turn, triggers the deletion of the
1200            ObjectToStringAdaptiveInferredPropertyValueWatchpoint O1.
1201
1202         After O1 is deleted in (6) and SD3 is allocated in (4), execution continues in
1203         AdaptiveInferredPropertyValueWatchpointBase::fire() where O1 gets installed in
1204         structure S3's watchpoint set.  This is obviously incorrect because O1 is already
1205         deleted.  The result is that badness happens later when S3's watchpoint set fires
1206         its watchpoints and accesses the deleted O1.
1207
1208         The fix is to enhance AdaptiveInferredPropertyValueWatchpointBase::fire() to
1209         check if "this" is still valid before proceeding to re-install itself or to
1210         invoke its handleFire() method.
1211
1212         ObjectToStringAdaptiveInferredPropertyValueWatchpoint (which extends
1213         AdaptiveInferredPropertyValueWatchpointBase) will override its isValid() method,
1214         and return false its owner StructureRareData is no longer reachable by the GC.
1215         This ensures that it won't be deleted while it's installed to any watchpoint set.
1216
1217         Additional considerations and notes:
1218         1. In the above, I talked about the ObjectToStringAdaptiveInferredPropertyValueWatchpoint
1219            being installed in watchpoint sets.  What actually happens is that
1220            ObjectToStringAdaptiveInferredPropertyValueWatchpoint has 2 members
1221            (m_structureWatchpoint and m_propertyWatchpoint) which may be installed in
1222            watchpoint sets.  The ObjectToStringAdaptiveInferredPropertyValueWatchpoint is
1223            not itself a Watchpoint object.
1224
1225            But for brevity, in the above, I refer to the ObjectToStringAdaptiveInferredPropertyValueWatchpoint
1226            instead of its Watchpoint members.  The description of the issue is still
1227            accurate given the life-cycle of the Watchpoint members are embedded in the
1228            enclosing ObjectToStringAdaptiveInferredPropertyValueWatchpoint object, and
1229            hence, they share the same life-cycle.
1230
1231         2. The top of AdaptiveInferredPropertyValueWatchpointBase::fire() removes its
1232            m_structureWatchpoint and m_propertyWatchpoint if they have been added to any
1233            watchpoint sets.  This is safe to do even if the owner StructureRareData is no
1234            longer reachable by the GC.
1235
1236            This is because the only way we can get to AdaptiveInferredPropertyValueWatchpointBase::fire()
1237            is if its Watchpoint members are still installed in some watchpoint set that
1238            fired.  This means that the AdaptiveInferredPropertyValueWatchpointBase
1239            instance has not been deleted yet, because its destructor will automatically
1240            remove the Watchpoint members from any watchpoint sets.
1241
1242         * bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp:
1243         (JSC::AdaptiveInferredPropertyValueWatchpointBase::fire):
1244         (JSC::AdaptiveInferredPropertyValueWatchpointBase::isValid):
1245         * bytecode/AdaptiveInferredPropertyValueWatchpointBase.h:
1246         * heap/FreeList.cpp:
1247         (JSC::FreeList::contains):
1248         * heap/FreeList.h:
1249         * heap/HeapCell.h:
1250         * heap/HeapCellInlines.h:
1251         (JSC::HeapCell::isLive):
1252         * heap/MarkedAllocator.h:
1253         (JSC::MarkedAllocator::isFreeListedCell):
1254         * heap/MarkedBlock.h:
1255         * heap/MarkedBlockInlines.h:
1256         (JSC::MarkedBlock::Handle::isFreeListedCell):
1257         * runtime/StructureRareData.cpp:
1258         (JSC::ObjectToStringAdaptiveInferredPropertyValueWatchpoint::isValid):
1259
1260 2017-05-23  Saam Barati  <sbarati@apple.com>
1261
1262         We should not mmap zero bytes for a memory in Wasm
1263         https://bugs.webkit.org/show_bug.cgi?id=172528
1264         <rdar://problem/32257076>
1265
1266         Reviewed by Mark Lam.
1267
1268         This patch fixes a bug where we would call into mmap with zero bytes
1269         when creating a slow WasmMemory with zero initial page size. This fix
1270         is simple: if we don't have any initial bytes, we just call the constructor
1271         in WasmMemory that's meant to handle this case.
1272
1273         * wasm/WasmMemory.cpp:
1274         (JSC::Wasm::Memory::create):
1275
1276 2017-05-23  Brian Burg  <bburg@apple.com>
1277
1278         REGRESSION(r217051): Automation sessions fail to complete bootstrap
1279         https://bugs.webkit.org/show_bug.cgi?id=172513
1280         <rdar://problem/32338354>
1281
1282         Reviewed by Joseph Pecoraro.
1283
1284         The changes to be more strict about typechecking messages were too strict.
1285
1286         * inspector/remote/cocoa/RemoteInspectorCocoa.mm:
1287         (Inspector::RemoteInspector::receivedSetupMessage):
1288         WIRAutomatically is an optional key in the setup message. In the relay, this key gets copied
1289         into an NSDictionary as NSNull if the key isn't present in a forwarded command.
1290         We need to revert NSNull values to nil, since it's valid to call [nil boolValue] but not
1291         [[NSNull null] boolValue]. We also need to allow for nil in the typecheck for this key.
1292
1293 2017-05-23  Myles C. Maxfield  <mmaxfield@apple.com>
1294
1295         Remove dead ENABLE(FONT_LOAD_EVENTS) code
1296         https://bugs.webkit.org/show_bug.cgi?id=172517
1297
1298         Rubber-stamped by Simon Fraser.
1299
1300         * Configurations/FeatureDefines.xcconfig:
1301
1302 2017-05-23  Saam Barati  <sbarati@apple.com>
1303
1304         CFGSimplificationPhase should not merge a block with itself
1305         https://bugs.webkit.org/show_bug.cgi?id=172508
1306         <rdar://problem/28424006>
1307
1308         Reviewed by Keith Miller.
1309
1310         CFGSimplificationPhase can run into or create IR that ends up with a
1311         block that has a Jump to itself, and no other predecessors. It should
1312         gracefully handle such IR. Before this patch, it would not. The only criteria
1313         for merging 'block' with 'targetBlock' used to be that 'targetBlock.predecessors.size() == 1'.
1314         The code is written in such a way that if we merge a block with itself, we
1315         will infinite loop until we run out of memory.
1316         
1317         Merging a block with itself does not make sense for a few reasons. First,
1318         we're joining the contents of two blocks. What is the definition of joining
1319         a block with itself? I suppose we could simply unroll this self loop
1320         one level, but that would not be wise because this self loop is by definition
1321         unreachable unless it's the root block in the graph (which I think is
1322         invalid IR since we'd never generate bytecode that would do this).
1323         
1324         This patch employs an easy fix: we can't merge a block with itself.
1325
1326         * dfg/DFGCFGSimplificationPhase.cpp:
1327         (JSC::DFG::CFGSimplificationPhase::canMergeBlocks):
1328         (JSC::DFG::CFGSimplificationPhase::run):
1329         (JSC::DFG::CFGSimplificationPhase::convertToJump):
1330         (JSC::DFG::CFGSimplificationPhase::mergeBlocks):
1331
1332 2017-05-22  Brian Burg  <bburg@apple.com>
1333
1334         Web Inspector: webkit reload policy should match default behavior
1335         https://bugs.webkit.org/show_bug.cgi?id=171385
1336         <rdar://problem/31871515>
1337
1338         Reviewed by Joseph Pecoraro.
1339
1340         Add a new option to Page.reload that allows the test harness
1341         to reload its test page using the old reload behavior.
1342
1343         The new behavior of revalidating expired cached subresources only
1344         is the current default, since only the test harness needs the old behavior.
1345
1346         * inspector/protocol/Page.json:
1347
1348 2017-05-22  Keith Miller  <keith_miller@apple.com>
1349
1350         [Cocoa] An exported Objective C class’s prototype and constructor don't persist across JSContext deallocation
1351         https://bugs.webkit.org/show_bug.cgi?id=167708
1352
1353         Reviewed by Geoffrey Garen.
1354
1355         This patch moves the Objective C wrapper map to the global object. In order to make this work the JSWrapperMap
1356         class no longer holds a reference to the JSContext. Instead, the context must be provided when getting a wrapper.
1357
1358         Also, this patch fixes a "bug" where we would observe changes to the Object property on the global object when
1359         creating a wrapper for NSObject.
1360
1361         * API/APICast.h:
1362         (toJSGlobalObject):
1363         * API/JSContext.mm:
1364         (-[JSContext ensureWrapperMap]):
1365         (-[JSContext initWithVirtualMachine:]):
1366         (-[JSContext dealloc]):
1367         (-[JSContext wrapperMap]):
1368         (-[JSContext initWithGlobalContextRef:]):
1369         (-[JSContext wrapperForObjCObject:]):
1370         (-[JSContext wrapperForJSObject:]):
1371         * API/JSWrapperMap.h:
1372         * API/JSWrapperMap.mm:
1373         (-[JSObjCClassInfo initForClass:]):
1374         (-[JSObjCClassInfo allocateConstructorAndPrototypeInContext:]):
1375         (-[JSObjCClassInfo wrapperForObject:inContext:]):
1376         (-[JSObjCClassInfo constructorInContext:]):
1377         (-[JSObjCClassInfo prototypeInContext:]):
1378         (-[JSWrapperMap initWithGlobalContextRef:]):
1379         (-[JSWrapperMap classInfoForClass:]):
1380         (-[JSWrapperMap jsWrapperForObject:inContext:]):
1381         (-[JSWrapperMap objcWrapperForJSValueRef:inContext:]):
1382         (-[JSObjCClassInfo initWithContext:forClass:]): Deleted.
1383         (-[JSObjCClassInfo allocateConstructorAndPrototype]): Deleted.
1384         (-[JSObjCClassInfo wrapperForObject:]): Deleted.
1385         (-[JSObjCClassInfo constructor]): Deleted.
1386         (-[JSObjCClassInfo prototype]): Deleted.
1387         (-[JSWrapperMap initWithContext:]): Deleted.
1388         (-[JSWrapperMap jsWrapperForObject:]): Deleted.
1389         (-[JSWrapperMap objcWrapperForJSValueRef:]): Deleted.
1390         * API/tests/JSExportTests.mm:
1391         (wrapperLifetimeIsTiedToGlobalObject):
1392         (runJSExportTests):
1393         * API/tests/testapi.mm:
1394         * runtime/JSGlobalObject.h:
1395         (JSC::JSGlobalObject::wrapperMap):
1396         (JSC::JSGlobalObject::setWrapperMap):
1397
1398 2017-05-22  Filip Pizlo  <fpizlo@apple.com>
1399
1400         FTL stack overflow handling should not assume that B3 never selects callee-saves in the prologue
1401         https://bugs.webkit.org/show_bug.cgi?id=172455
1402
1403         Reviewed by Mark Lam.
1404         
1405         The FTL needs to run B3's callee-save register restoration before it runs the exception
1406         handler's callee-save register restoration.  This exposes B3's callee-save register
1407         algorithm in AssemblyHelpers so that the FTL can call it.
1408
1409         * b3/air/AirGenerate.cpp:
1410         (JSC::B3::Air::generate):
1411         * ftl/FTLLowerDFGToB3.cpp:
1412         (JSC::FTL::DFG::LowerDFGToB3::lower): Fix the bug.
1413         * heap/Subspace.cpp: Added some debugging support.
1414         (JSC::Subspace::allocate):
1415         (JSC::Subspace::tryAllocate):
1416         (JSC::Subspace::didAllocate):
1417         * heap/Subspace.h:
1418         * jit/AssemblyHelpers.h:
1419         (JSC::AssemblyHelpers::addressFor):
1420         (JSC::AssemblyHelpers::emitSave):
1421         (JSC::AssemblyHelpers::emitRestore):
1422
1423 2017-05-20  Yusuke Suzuki  <utatane.tea@gmail.com>
1424
1425         [FTL] Support GetByVal with ArrayStorage and SlowPutArrayStorage
1426         https://bugs.webkit.org/show_bug.cgi?id=172216
1427
1428         Reviewed by Saam Barati.
1429
1430         This patch adds GetByVal support for ArrayStorage and SlowPutArrayStorage.
1431         To lower CheckInBounds in FTL, we add a new GetVectorLength op. It only accepts
1432         ArrayStorage and SlowPutArrayStorage, then it produces vector length.
1433         CheckInBounds uses this vector length to perform bound checking for ArrayStorage
1434         and SlowPutArrayStorage.
1435
1436         * dfg/DFGAbstractInterpreterInlines.h:
1437         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1438         * dfg/DFGArrayMode.cpp:
1439         (JSC::DFG::permitsBoundsCheckLowering):
1440         * dfg/DFGClobberize.h:
1441         (JSC::DFG::clobberize):
1442         * dfg/DFGDoesGC.cpp:
1443         (JSC::DFG::doesGC):
1444         * dfg/DFGFixupPhase.cpp:
1445         (JSC::DFG::FixupPhase::fixupNode):
1446         * dfg/DFGHeapLocation.cpp:
1447         (WTF::printInternal):
1448         * dfg/DFGHeapLocation.h:
1449         * dfg/DFGIntegerRangeOptimizationPhase.cpp:
1450         * dfg/DFGNode.h:
1451         (JSC::DFG::Node::hasArrayMode):
1452         * dfg/DFGNodeType.h:
1453         * dfg/DFGPredictionPropagationPhase.cpp:
1454         * dfg/DFGSSALoweringPhase.cpp:
1455         (JSC::DFG::SSALoweringPhase::lowerBoundsCheck):
1456         * dfg/DFGSafeToExecute.h:
1457         (JSC::DFG::safeToExecute):
1458         * dfg/DFGSpeculativeJIT32_64.cpp:
1459         (JSC::DFG::SpeculativeJIT::compile):
1460         * dfg/DFGSpeculativeJIT64.cpp:
1461         (JSC::DFG::SpeculativeJIT::compile):
1462         * ftl/FTLAbstractHeapRepository.h:
1463         (JSC::FTL::AbstractHeapRepository::forIndexingType):
1464         (JSC::FTL::AbstractHeapRepository::forArrayType):
1465         * ftl/FTLCapabilities.cpp:
1466         (JSC::FTL::canCompile):
1467         * ftl/FTLLowerDFGToB3.cpp:
1468         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1469         (JSC::FTL::DFG::LowerDFGToB3::compileGetVectorLength):
1470         (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
1471         * jit/JITPropertyAccess.cpp:
1472         (JSC::JIT::emitArrayStoragePutByVal):
1473         * jit/JITPropertyAccess32_64.cpp:
1474         (JSC::JIT::emitArrayStorageLoad):
1475         (JSC::JIT::emitArrayStoragePutByVal):
1476
1477 2017-05-21  Saam Barati  <sbarati@apple.com>
1478
1479         We incorrectly throw a syntax error when declaring a top level for-loop iteration variable the same as a parameter
1480         https://bugs.webkit.org/show_bug.cgi?id=171041
1481         <rdar://problem/32082516>
1482
1483         Reviewed by Yusuke Suzuki.
1484
1485         We were treating a for-loop variable declaration potentially as a top
1486         level statement, e.g, in a program like this:
1487         ```
1488         function foo() {
1489             for (let variable of expr) { }
1490         }
1491         ```
1492         But we should not be. This had the consequence of making this type of program
1493         throw a syntax error:
1494         ```
1495         function foo(arg) {
1496             for (let arg of expr) { }
1497         }
1498         ```
1499         even though it should not. The fix is simple, we just need to increment the
1500         statement depth before parsing anything inside the for loop.
1501
1502         * parser/Parser.cpp:
1503         (JSC::Parser<LexerType>::parseForStatement):
1504
1505 2017-05-19  Yusuke Suzuki  <utatane.tea@gmail.com>
1506
1507         [JSC] Make get_by_val & string "499" to number 499
1508         https://bugs.webkit.org/show_bug.cgi?id=172225
1509
1510         Reviewed by Saam Barati.
1511
1512         Property subscript will be converted by ToString. So JS code is not aware of
1513         the original type of the subscript value. But our get_by_val can leverage
1514         information if the given subscript is number. Thus, passing number instead of
1515         string can improve the performance of get_by_val in all the tiers.
1516
1517         In this patch, we add BytecodeGenerator::emitNodeForProperty. It attempts to
1518         convert the given value to Int32 index constant if the given value is a string
1519         that can be converted to Int32.
1520
1521         This patch improves SixSpeed map-string.es5 by 9.8x. This accessing form can
1522         appear in some code like accessing the result of JSON.
1523
1524             map-string.es5     1640.6738+-110.9182   ^    167.4121+-23.8328       ^ definitely 9.8002x faster
1525
1526         * bytecompiler/BytecodeGenerator.h:
1527         (JSC::BytecodeGenerator::emitNodeForProperty):
1528         (JSC::BytecodeGenerator::emitNodeForLeftHandSideForProperty):
1529         * bytecompiler/NodesCodegen.cpp:
1530         (JSC::TaggedTemplateNode::emitBytecode):
1531         (JSC::BracketAccessorNode::emitBytecode):
1532         (JSC::BytecodeIntrinsicNode::emit_intrinsic_putByValDirect):
1533         (JSC::FunctionCallBracketNode::emitBytecode):
1534         (JSC::PostfixNode::emitBracket):
1535         (JSC::PrefixNode::emitBracket):
1536         (JSC::AssignBracketNode::emitBytecode):
1537         (JSC::ReadModifyBracketNode::emitBytecode):
1538         (JSC::ForInNode::emitLoopHeader):
1539         (JSC::ForOfNode::emitBytecode):
1540         (JSC::ObjectPatternNode::bindValue):
1541         (JSC::AssignmentElementNode::bindValue):
1542
1543 2017-05-21  Saam Barati  <sbarati@apple.com>
1544
1545         We overwrite the callee save space on the stack when throwing stack overflow from wasm
1546         https://bugs.webkit.org/show_bug.cgi?id=172316
1547
1548         Reviewed by Mark Lam.
1549
1550         When throwing a stack overflow exception, the overflow
1551         thunk would do the following:
1552           move fp, sp
1553           populate argument registers
1554           call C code
1555         
1556         However, the C function is allowed to clobber our spilled
1557         callee saves that live below fp. The reason I did this move is that
1558         when we jump to this code, we've proven that sp is out of bounds on
1559         the stack. So we're not allowed to just use its value or keep growing
1560         the stack from that point. However, this patch revises this approach
1561         to be the same in spirit, but actually correct. We conservatively assume
1562         the B3 function we're coming from could have saved all callee saves.
1563         So we emit code like this now:
1564           add -maxNumCalleeSaveSpace, fp, sp
1565           populate argument registers
1566           call C code
1567         
1568         This ensures our callee saves will not be overwritten. Note
1569         that fp is still in a valid stack range here, since the thing
1570         calling the wasm code did a stack check. Also note that maxNumCalleeSaveSpace
1571         is less than our redzone size, so it's safe to decrement sp by 
1572         this amount.
1573         
1574         The previously added wasm stack overflow test is an instance crash
1575         without this change on arm64. It also appears that this test crashed
1576         on some other x86 devices.
1577
1578         * wasm/WasmThunks.cpp:
1579         (JSC::Wasm::throwStackOverflowFromWasmThunkGenerator):
1580
1581 2017-05-20  Chris Dumez  <cdumez@apple.com>
1582
1583         Drop [NoInterfaceObject] from RTCDTMFSender and RTCStatsReport
1584         https://bugs.webkit.org/show_bug.cgi?id=172418
1585
1586         Reviewed by Youenn Fablet.
1587
1588         Add CommonIdentifiers that are now needed.
1589
1590         * runtime/CommonIdentifiers.h:
1591
1592 2017-05-20  Yusuke Suzuki  <utatane.tea@gmail.com>
1593
1594         Unreviewed, add scope.release() to propertyIsEnumerable functions.
1595         https://bugs.webkit.org/show_bug.cgi?id=172411
1596
1597         * runtime/JSGlobalObjectFunctions.cpp:
1598         (JSC::globalFuncPropertyIsEnumerable):
1599         * runtime/ObjectPrototype.cpp:
1600         (JSC::objectProtoFuncPropertyIsEnumerable):
1601
1602 2017-05-20  Yusuke Suzuki  <utatane.tea@gmail.com>
1603
1604         [JSC] Drop MapBase
1605         https://bugs.webkit.org/show_bug.cgi?id=172417
1606
1607         Reviewed by Sam Weinig.
1608
1609         MapBase is a purely additional indirection. JSMap and JSSet can directly inherit HashMapImpl.
1610         Thus MapBase is unnecessary. This patch drops it.
1611         It is good because we can eliminate one indirection when accessing to map implementation.
1612         Moreover, we can drop one unnecessary allocation per Map and Set.
1613
1614         * CMakeLists.txt:
1615         * JavaScriptCore.xcodeproj/project.pbxproj:
1616         * dfg/DFGSpeculativeJIT64.cpp:
1617         (JSC::DFG::SpeculativeJIT::compile):
1618         * ftl/FTLAbstractHeapRepository.h:
1619         * ftl/FTLLowerDFGToB3.cpp:
1620         (JSC::FTL::DFG::LowerDFGToB3::compileGetMapBucket):
1621         * runtime/HashMapImpl.cpp:
1622         (JSC::HashMapImpl<HashMapBucket>::estimatedSize):
1623         (JSC::getHashMapImplKeyClassInfo): Deleted.
1624         (JSC::getHashMapImplKeyValueClassInfo): Deleted.
1625         * runtime/HashMapImpl.h:
1626         (JSC::HashMapImpl::finishCreation):
1627         (JSC::HashMapImpl::get):
1628         (JSC::HashMapImpl::info): Deleted.
1629         (JSC::HashMapImpl::createStructure): Deleted.
1630         (JSC::HashMapImpl::create): Deleted.
1631         * runtime/JSMap.h:
1632         (JSC::JSMap::set):
1633         (JSC::JSMap::get): Deleted.
1634         * runtime/JSMapIterator.cpp:
1635         (JSC::JSMapIterator::finishCreation):
1636         * runtime/JSSet.h:
1637         (JSC::JSSet::add): Deleted.
1638         * runtime/JSSetIterator.cpp:
1639         (JSC::JSSetIterator::finishCreation):
1640         * runtime/MapBase.cpp: Removed.
1641         * runtime/MapBase.h: Removed.
1642         * runtime/MapPrototype.cpp:
1643         (JSC::mapProtoFuncSize):
1644         * runtime/SetConstructor.cpp:
1645         (JSC::constructSet):
1646         * runtime/SetPrototype.cpp:
1647         (JSC::setProtoFuncSize):
1648         * runtime/VM.cpp:
1649         (JSC::VM::VM):
1650
1651 2017-05-20  Yusuke Suzuki  <utatane.tea@gmail.com>
1652
1653         [JSC] Speedup Object.assign for slow case by using propertyIsEnumerable
1654         https://bugs.webkit.org/show_bug.cgi?id=172411
1655
1656         Reviewed by Sam Weinig.
1657
1658         We use @Reflect.@getOwnPropertyDescriptor() to check
1659
1660         1. the descriptor exists,
1661         2. and the descriptor.enumrable is true
1662
1663         But Object::propertyIsEnumerable does the completely same thing without
1664         allocating a new object for property descriptor.
1665
1666         In this patch, we add a new private function @propertyIsEnumerable, and
1667         use it in Object.assign implementation. It does not allocate unnecessary
1668         objects. It is good for GC-pressure and performance.
1669
1670         This patch improves SixSpeed object-assign.es6 by 1.7x. While this patch
1671         does not introduce a fast path for objects that do not have accessors,
1672         and it could speed up things further, this patch can speed up the common
1673         slow path cases that is the current implementation of Object.assign.
1674
1675             object-assign.es6     1103.2487+-21.5602    ^    621.8478+-34.9875       ^ definitely 1.7741x faster
1676
1677         * builtins/BuiltinNames.h:
1678         * builtins/ObjectConstructor.js:
1679         (globalPrivate.enumerableOwnProperties):
1680         (assign):
1681         * runtime/JSGlobalObject.cpp:
1682         (JSC::JSGlobalObject::init):
1683         * runtime/JSGlobalObjectFunctions.cpp:
1684         (JSC::globalFuncPropertyIsEnumerable):
1685         * runtime/JSGlobalObjectFunctions.h:
1686
1687 2017-05-19  Yusuke Suzuki  <utatane.tea@gmail.com>
1688
1689         [JSC] Enable testapi on Mac CMake build
1690         https://bugs.webkit.org/show_bug.cgi?id=172354
1691
1692         Reviewed by Alex Christensen.
1693
1694         This patch makes testapi buildable and runnable for Mac CMake port.
1695
1696         * API/tests/DateTests.mm:
1697         (+[DateTests JSDateToNSDateTest]):
1698         (+[DateTests roundTripThroughJSDateTest]):
1699         This test only works with the en_US locale.
1700
1701         * shell/CMakeLists.txt:
1702         * shell/PlatformMac.cmake:
1703         Some of tests rely on ARC. We enable ARC for those files.
1704
1705         * shell/PlatformWin.cmake:
1706         Clean up.
1707
1708 2017-05-19  Mark Lam  <mark.lam@apple.com>
1709
1710         [Re-landing] DFG::SpeculativeJIT::pickCanTrample() is wrongly ignoring result registers.
1711         https://bugs.webkit.org/show_bug.cgi?id=172383
1712         <rdar://problem/31418651>
1713
1714         Reviewed by Filip Pizlo.
1715
1716         pickCanTrample() is wrongly assuming that one of regT0 and regT1 is always
1717         available as a scratch register.  This assumption is wrong if this canTrample
1718         register is used for a silentFill() after an operation that returns a result in
1719         regT0 or regT1.
1720
1721         Turns out the only reason we need the canTrample register is for
1722         SetDoubleConstant.  We can remove the need for this canTrample register by
1723         introducing a moveDouble() pseudo instruction in the MacroAssembler to do the
1724         job using the scratchRegister() on X86_64 or the dataMemoryTempRegister() on
1725         ARM64.  In so doing, we can simplify the silentFill() code and eliminate the bug.
1726
1727         Update for re-landing: Changed ARM64 to use scratchRegister() as well.
1728         scratchRegister() is the proper way to get the underlying dataMemoryTempRegister()
1729         as a scratch register.
1730
1731         * assembler/MacroAssembler.h:
1732         (JSC::MacroAssembler::moveDouble):
1733         * dfg/DFGArrayifySlowPathGenerator.h:
1734         * dfg/DFGCallArrayAllocatorSlowPathGenerator.h:
1735         (JSC::DFG::CallArrayAllocatorWithVariableStructureVariableSizeSlowPathGenerator::CallArrayAllocatorWithVariableStructureVariableSizeSlowPathGenerator):
1736         * dfg/DFGCallCreateDirectArgumentsSlowPathGenerator.h:
1737         * dfg/DFGSaneStringGetByValSlowPathGenerator.h:
1738         * dfg/DFGSlowPathGenerator.h:
1739         (JSC::DFG::CallSlowPathGenerator::tearDown):
1740         * dfg/DFGSpeculativeJIT.cpp:
1741         (JSC::DFG::SpeculativeJIT::silentFill):
1742         (JSC::DFG::SpeculativeJIT::compileToLowerCase):
1743         (JSC::DFG::SpeculativeJIT::compileValueToInt32):
1744         (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
1745         (JSC::DFG::SpeculativeJIT::emitUntypedBitOp):
1746         (JSC::DFG::SpeculativeJIT::emitUntypedRightShiftBitOp):
1747         (JSC::DFG::SpeculativeJIT::compileArithDiv):
1748         (JSC::DFG::SpeculativeJIT::compileArraySlice):
1749         (JSC::DFG::SpeculativeJIT::emitSwitchImm):
1750         (JSC::DFG::SpeculativeJIT::emitSwitchStringOnString):
1751         (JSC::DFG::SpeculativeJIT::compileStoreBarrier):
1752         * dfg/DFGSpeculativeJIT.h:
1753         (JSC::DFG::SpeculativeJIT::silentFill):
1754         (JSC::DFG::SpeculativeJIT::silentSpillAllRegisters):
1755         (JSC::DFG::SpeculativeJIT::silentFillAllRegisters):
1756         (JSC::DFG::SpeculativeJIT::pickCanTrample): Deleted.
1757         * dfg/DFGSpeculativeJIT32_64.cpp:
1758         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch):
1759         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq):
1760         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq):
1761         (JSC::DFG::SpeculativeJIT::emitCall):
1762         (JSC::DFG::SpeculativeJIT::compile):
1763         * dfg/DFGSpeculativeJIT64.cpp:
1764         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch):
1765         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq):
1766         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq):
1767         (JSC::DFG::SpeculativeJIT::emitCall):
1768         (JSC::DFG::SpeculativeJIT::compile):
1769         (JSC::DFG::SpeculativeJIT::convertAnyInt):
1770
1771 2017-05-19  Ryan Haddad  <ryanhaddad@apple.com>
1772
1773         Unreviewed, rolling out r217156.
1774
1775         This change broke the iOS build.
1776
1777         Reverted changeset:
1778
1779         "DFG::SpeculativeJIT::pickCanTrample() is wrongly ignoring
1780         result registers."
1781         https://bugs.webkit.org/show_bug.cgi?id=172383
1782         http://trac.webkit.org/changeset/217156
1783
1784 2017-05-19  Mark Lam  <mark.lam@apple.com>
1785
1786         Add missing exception check.
1787         https://bugs.webkit.org/show_bug.cgi?id=172346
1788         <rdar://problem/32289640>
1789
1790         Reviewed by Geoffrey Garen.
1791
1792         * runtime/JSObject.cpp:
1793         (JSC::JSObject::hasInstance):
1794
1795 2017-05-19  Mark Lam  <mark.lam@apple.com>
1796
1797         DFG::SpeculativeJIT::pickCanTrample() is wrongly ignoring result registers.
1798         https://bugs.webkit.org/show_bug.cgi?id=172383
1799         <rdar://problem/31418651>
1800
1801         Reviewed by Filip Pizlo.
1802
1803         pickCanTrample() is wrongly assuming that one of regT0 and regT1 is always
1804         available as a scratch register.  This assumption is wrong if this canTrample
1805         register is used for a silentFill() after an operation that returns a result in
1806         regT0 or regT1.
1807
1808         Turns out the only reason we need the canTrample register is for
1809         SetDoubleConstant.  We can remove the need for this canTrample register by
1810         introducing a moveDouble() pseudo instruction in the MacroAssembler to do the
1811         job using the scratchRegister() on X86_64 or the dataMemoryTempRegister() on
1812         ARM64.  In so doing, we can simplify the silentFill() code and eliminate the bug.
1813
1814         * assembler/MacroAssembler.h:
1815         (JSC::MacroAssembler::moveDouble):
1816         * dfg/DFGArrayifySlowPathGenerator.h:
1817         * dfg/DFGCallArrayAllocatorSlowPathGenerator.h:
1818         (JSC::DFG::CallArrayAllocatorWithVariableStructureVariableSizeSlowPathGenerator::CallArrayAllocatorWithVariableStructureVariableSizeSlowPathGenerator):
1819         * dfg/DFGCallCreateDirectArgumentsSlowPathGenerator.h:
1820         * dfg/DFGSaneStringGetByValSlowPathGenerator.h:
1821         * dfg/DFGSlowPathGenerator.h:
1822         (JSC::DFG::CallSlowPathGenerator::tearDown):
1823         * dfg/DFGSpeculativeJIT.cpp:
1824         (JSC::DFG::SpeculativeJIT::silentFill):
1825         (JSC::DFG::SpeculativeJIT::compileToLowerCase):
1826         (JSC::DFG::SpeculativeJIT::compileValueToInt32):
1827         (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
1828         (JSC::DFG::SpeculativeJIT::emitUntypedBitOp):
1829         (JSC::DFG::SpeculativeJIT::emitUntypedRightShiftBitOp):
1830         (JSC::DFG::SpeculativeJIT::compileArithDiv):
1831         (JSC::DFG::SpeculativeJIT::compileArraySlice):
1832         (JSC::DFG::SpeculativeJIT::emitSwitchImm):
1833         (JSC::DFG::SpeculativeJIT::emitSwitchStringOnString):
1834         (JSC::DFG::SpeculativeJIT::compileStoreBarrier):
1835         * dfg/DFGSpeculativeJIT.h:
1836         (JSC::DFG::SpeculativeJIT::silentFill):
1837         (JSC::DFG::SpeculativeJIT::silentSpillAllRegisters):
1838         (JSC::DFG::SpeculativeJIT::silentFillAllRegisters):
1839         (JSC::DFG::SpeculativeJIT::pickCanTrample): Deleted.
1840         * dfg/DFGSpeculativeJIT32_64.cpp:
1841         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch):
1842         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq):
1843         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq):
1844         (JSC::DFG::SpeculativeJIT::emitCall):
1845         (JSC::DFG::SpeculativeJIT::compile):
1846         * dfg/DFGSpeculativeJIT64.cpp:
1847         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch):
1848         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq):
1849         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq):
1850         (JSC::DFG::SpeculativeJIT::emitCall):
1851         (JSC::DFG::SpeculativeJIT::compile):
1852         (JSC::DFG::SpeculativeJIT::convertAnyInt):
1853
1854 2017-05-19  Filip Pizlo  <fpizlo@apple.com>
1855
1856         Deduplicate some code in arrayProtoPrivateFuncConcatMemcpy
1857         https://bugs.webkit.org/show_bug.cgi?id=172382
1858
1859         Reviewed by Saam Barati.
1860         
1861         This is just a small clean-up - my last patch here created some unnecessary code duplication.
1862
1863         * runtime/ArrayPrototype.cpp:
1864         (JSC::arrayProtoPrivateFuncConcatMemcpy):
1865
1866 2017-05-19  Filip Pizlo  <fpizlo@apple.com>
1867
1868         arrayProtoPrivateFuncConcatMemcpy needs to be down with firstArray being undecided
1869         https://bugs.webkit.org/show_bug.cgi?id=172369
1870
1871         Reviewed by Mark Lam.
1872
1873         * heap/Subspace.cpp: Reshaped the code a bit to aid debugging.
1874         (JSC::Subspace::allocate):
1875         (JSC::Subspace::tryAllocate):
1876         * runtime/ArrayPrototype.cpp:
1877         (JSC::arrayProtoPrivateFuncConcatMemcpy): Fix the bug!
1878         * runtime/ObjectInitializationScope.cpp: Provide even better feedback.
1879         (JSC::ObjectInitializationScope::verifyPropertiesAreInitialized):
1880
1881 2017-05-18  Filip Pizlo  <fpizlo@apple.com>
1882
1883         B3::Value::effects() says that having a fence range implies the fence bit, but on x86_64 we lower loadAcq/storeRel to load/store so the store-before-load fence bit orderings won't be honored
1884         https://bugs.webkit.org/show_bug.cgi?id=172306
1885
1886         Reviewed by Michael Saboff.
1887         
1888         This changes B3 to emit xchg and its variants for fenced stores on x86. This ensures that
1889         fenced stores cannot be reordered around other fenced instructions. Previously, B3 emitted
1890         normal store instructions for fenced stores. That's wrong because then you get reorderings
1891         that are possible in TSO but impossible in SC. Fenced instructions are supposed to be SC
1892         with respect for each other.
1893         
1894         This is imprecise. If you really just wanted a store-release, then every X86 store does this.
1895         But, in B3, fenced stores are ARM-style store-release, meaning that they are fenced with
1896         respect to all other fences. If we ever did want to say that something is a store release in
1897         the traditional sense, then we'd want MemoryValue to have a fence flag. Then, having a fence
1898         range without the fence flag would mean the traditional store-release, which lowers to a
1899         normal store on x86. But to my knowledge, that traditional store-release is only useful for
1900         unlocking spinlocks. We don't use spinlocks in JSC. Adaptive locks require CAS for unlock,
1901         and B3 CAS is plenty fast. I think it's OK to have this small imprecision of giving clients
1902         an ARM-style store-release on x86 using xchg.
1903         
1904         The implication of this change is that the FTL no longer violates the SAB memory model.
1905
1906         * assembler/MacroAssemblerX86Common.h:
1907         (JSC::MacroAssemblerX86Common::xchg8):
1908         (JSC::MacroAssemblerX86Common::xchg16):
1909         (JSC::MacroAssemblerX86Common::xchg32):
1910         (JSC::MacroAssemblerX86Common::loadAcq8): Deleted.
1911         (JSC::MacroAssemblerX86Common::loadAcq8SignedExtendTo32): Deleted.
1912         (JSC::MacroAssemblerX86Common::loadAcq16): Deleted.
1913         (JSC::MacroAssemblerX86Common::loadAcq16SignedExtendTo32): Deleted.
1914         (JSC::MacroAssemblerX86Common::loadAcq32): Deleted.
1915         (JSC::MacroAssemblerX86Common::storeRel8): Deleted.
1916         (JSC::MacroAssemblerX86Common::storeRel16): Deleted.
1917         (JSC::MacroAssemblerX86Common::storeRel32): Deleted.
1918         * assembler/MacroAssemblerX86_64.h:
1919         (JSC::MacroAssemblerX86_64::xchg64):
1920         (JSC::MacroAssemblerX86_64::loadAcq64): Deleted.
1921         (JSC::MacroAssemblerX86_64::storeRel64): Deleted.
1922         * b3/B3LowerToAir.cpp:
1923         (JSC::B3::Air::LowerToAir::ArgPromise::inst):
1924         (JSC::B3::Air::LowerToAir::trappingInst):
1925         (JSC::B3::Air::LowerToAir::tryAppendStoreBinOp):
1926         (JSC::B3::Air::LowerToAir::createStore):
1927         (JSC::B3::Air::LowerToAir::storeOpcode):
1928         (JSC::B3::Air::LowerToAir::appendStore):
1929         (JSC::B3::Air::LowerToAir::append):
1930         (JSC::B3::Air::LowerToAir::appendTrapping):
1931         (JSC::B3::Air::LowerToAir::fillStackmap):
1932         (JSC::B3::Air::LowerToAir::lower):
1933         * b3/air/AirKind.cpp:
1934         (JSC::B3::Air::Kind::dump):
1935         * b3/air/AirKind.h:
1936         (JSC::B3::Air::Kind::Kind):
1937         (JSC::B3::Air::Kind::operator==):
1938         (JSC::B3::Air::Kind::hash):
1939         * b3/air/AirLowerAfterRegAlloc.cpp:
1940         (JSC::B3::Air::lowerAfterRegAlloc):
1941         * b3/air/AirLowerMacros.cpp:
1942         (JSC::B3::Air::lowerMacros):
1943         * b3/air/AirOpcode.opcodes:
1944         * b3/air/AirValidate.cpp:
1945         * b3/air/opcode_generator.rb:
1946         * b3/testb3.cpp:
1947         (JSC::B3::correctSqrt):
1948         (JSC::B3::testSqrtArg):
1949         (JSC::B3::testSqrtImm):
1950         (JSC::B3::testSqrtMem):
1951         (JSC::B3::testSqrtArgWithUselessDoubleConversion):
1952         (JSC::B3::testSqrtArgWithEffectfulDoubleConversion):
1953         (JSC::B3::testStoreRelAddLoadAcq32):
1954         (JSC::B3::testTrappingLoad):
1955         (JSC::B3::testTrappingStore):
1956         (JSC::B3::testTrappingLoadAddStore):
1957         (JSC::B3::testTrappingLoadDCE):
1958
1959 2017-05-19  Don Olmstead  <don.olmstead@am.sony.com>
1960
1961         [JSC] Remove PLATFORM(WIN) references
1962         https://bugs.webkit.org/show_bug.cgi?id=172294
1963
1964         Reviewed by Yusuke Suzuki.
1965
1966         * heap/MachineStackMarker.cpp:
1967         (JSC::MachineThreads::removeThread):
1968         * llint/LLIntOfflineAsmConfig.h:
1969         * runtime/ConfigFile.h:
1970         * runtime/VM.cpp:
1971         (JSC::VM::updateStackLimits):
1972
1973 2017-05-19  Yusuke Suzuki  <utatane.tea@gmail.com>
1974
1975         [JSC][DFG][DOMJIT] Extend CheckDOM to CheckSubClass
1976         https://bugs.webkit.org/show_bug.cgi?id=172098
1977
1978         Reviewed by Saam Barati.
1979
1980         In this patch, we generalize CheckDOM to CheckSubClass.
1981         It can accept any ClassInfo and perform ClassInfo check
1982         in DFG / FTL. Now, we add a new function pointer to ClassInfo,
1983         checkSubClassPatchpoint. It can create DOMJIT patchpoint
1984         for that ClassInfo. It it natural that ClassInfo holds the
1985         way to emit DOMJIT::Patchpoint to perform CheckSubClass
1986         rather than having it in each DOMJIT getter / function
1987         signature annotation.
1988
1989         One problem is that it enlarges the size of ClassInfo.
1990         But this is the best place to put this function pointer.
1991         By doing so, we can add a patchpoint for CheckSubClass
1992         in an non-intrusive manner: WebCore can inject patchpoints
1993         without interactive JSC.
1994
1995         We still have a way to reduce the size of ClassInfo if
1996         we move ArrayBuffer related methods out to the other places.
1997
1998         This patch touches many files because we add a new function
1999         pointer to ClassInfo. But they are basically mechanical change.
2000
2001         * API/JSAPIWrapperObject.mm:
2002         * API/JSCallbackConstructor.cpp:
2003         * API/JSCallbackFunction.cpp:
2004         * API/JSCallbackObject.cpp:
2005         * API/ObjCCallbackFunction.mm:
2006         * CMakeLists.txt:
2007         * JavaScriptCore.xcodeproj/project.pbxproj:
2008         * bytecode/CodeBlock.cpp:
2009         * bytecode/DOMJITAccessCasePatchpointParams.h:
2010         (JSC::DOMJITAccessCasePatchpointParams::DOMJITAccessCasePatchpointParams):
2011         * bytecode/EvalCodeBlock.cpp:
2012         * bytecode/FunctionCodeBlock.cpp:
2013         * bytecode/GetterSetterAccessCase.cpp:
2014         (JSC::GetterSetterAccessCase::emitDOMJITGetter):
2015         * bytecode/ModuleProgramCodeBlock.cpp:
2016         * bytecode/ProgramCodeBlock.cpp:
2017         * bytecode/UnlinkedCodeBlock.cpp:
2018         * bytecode/UnlinkedEvalCodeBlock.cpp:
2019         * bytecode/UnlinkedFunctionCodeBlock.cpp:
2020         * bytecode/UnlinkedFunctionExecutable.cpp:
2021         * bytecode/UnlinkedModuleProgramCodeBlock.cpp:
2022         * bytecode/UnlinkedProgramCodeBlock.cpp:
2023         * debugger/DebuggerScope.cpp:
2024         * dfg/DFGAbstractInterpreterInlines.h:
2025         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2026         * dfg/DFGByteCodeParser.cpp:
2027         (JSC::DFG::ByteCodeParser::handleDOMJITGetter):
2028         * dfg/DFGClobberize.h:
2029         (JSC::DFG::clobberize):
2030         * dfg/DFGConstantFoldingPhase.cpp:
2031         (JSC::DFG::ConstantFoldingPhase::foldConstants):
2032         * dfg/DFGDOMJITPatchpointParams.h:
2033         (JSC::DFG::DOMJITPatchpointParams::DOMJITPatchpointParams):
2034         * dfg/DFGDoesGC.cpp:
2035         (JSC::DFG::doesGC):
2036         * dfg/DFGFixupPhase.cpp:
2037         (JSC::DFG::FixupPhase::fixupNode):
2038         (JSC::DFG::FixupPhase::attemptToMakeCallDOM):
2039         (JSC::DFG::FixupPhase::fixupCheckSubClass):
2040         (JSC::DFG::FixupPhase::fixupCheckDOM): Deleted.
2041         * dfg/DFGGraph.cpp:
2042         (JSC::DFG::Graph::dump):
2043         * dfg/DFGNode.h:
2044         (JSC::DFG::Node::hasClassInfo):
2045         (JSC::DFG::Node::classInfo):
2046         (JSC::DFG::Node::hasCheckDOMPatchpoint): Deleted.
2047         (JSC::DFG::Node::checkDOMPatchpoint): Deleted.
2048         * dfg/DFGNodeType.h:
2049         * dfg/DFGPredictionPropagationPhase.cpp:
2050         * dfg/DFGSafeToExecute.h:
2051         (JSC::DFG::safeToExecute):
2052         * dfg/DFGSpeculativeJIT.cpp:
2053         (JSC::DFG::SpeculativeJIT::compileCheckSubClass):
2054         (JSC::DFG::SpeculativeJIT::compileCheckDOM): Deleted.
2055         * dfg/DFGSpeculativeJIT.h:
2056         (JSC::DFG::SpeculativeJIT::vm):
2057         * dfg/DFGSpeculativeJIT32_64.cpp:
2058         (JSC::DFG::SpeculativeJIT::compile):
2059         * dfg/DFGSpeculativeJIT64.cpp:
2060         (JSC::DFG::SpeculativeJIT::compile):
2061         * domjit/DOMJITGetterSetter.h:
2062         * domjit/DOMJITPatchpointParams.h:
2063         (JSC::DOMJIT::PatchpointParams::PatchpointParams):
2064         (JSC::DOMJIT::PatchpointParams::vm):
2065         * domjit/DOMJITSignature.h:
2066         (JSC::DOMJIT::Signature::Signature):
2067         (JSC::DOMJIT::Signature::checkDOM): Deleted.
2068         * ftl/FTLAbstractHeapRepository.h:
2069         * ftl/FTLCapabilities.cpp:
2070         (JSC::FTL::canCompile):
2071         * ftl/FTLDOMJITPatchpointParams.h:
2072         (JSC::FTL::DOMJITPatchpointParams::DOMJITPatchpointParams):
2073         * ftl/FTLLowerDFGToB3.cpp:
2074         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2075         (JSC::FTL::DFG::LowerDFGToB3::compileCheckSubClass):
2076         (JSC::FTL::DFG::LowerDFGToB3::compileCheckDOM): Deleted.
2077         * inspector/JSInjectedScriptHost.cpp:
2078         * inspector/JSInjectedScriptHostPrototype.cpp:
2079         * inspector/JSJavaScriptCallFrame.cpp:
2080         * inspector/JSJavaScriptCallFramePrototype.cpp:
2081         * jsc.cpp:
2082         (WTF::DOMJITNode::checkSubClassPatchpoint):
2083         (WTF::DOMJITFunctionObject::checkSubClassPatchpoint):
2084         (WTF::DOMJITFunctionObject::finishCreation):
2085         (WTF::DOMJITCheckSubClassObject::DOMJITCheckSubClassObject):
2086         (WTF::DOMJITCheckSubClassObject::createStructure):
2087         (WTF::DOMJITCheckSubClassObject::create):
2088         (WTF::DOMJITCheckSubClassObject::safeFunction):
2089         (WTF::DOMJITCheckSubClassObject::unsafeFunction):
2090         (WTF::DOMJITCheckSubClassObject::finishCreation):
2091         (GlobalObject::finishCreation):
2092         (functionCreateDOMJITCheckSubClassObject):
2093         (WTF::DOMJITNode::checkDOMJITNode): Deleted.
2094         (WTF::DOMJITFunctionObject::checkDOMJITNode): Deleted.
2095         * runtime/AbstractModuleRecord.cpp:
2096         * runtime/ArrayBufferNeuteringWatchpoint.cpp:
2097         * runtime/ArrayConstructor.cpp:
2098         * runtime/ArrayIteratorPrototype.cpp:
2099         * runtime/ArrayPrototype.cpp:
2100         * runtime/AsyncFunctionConstructor.cpp:
2101         * runtime/AsyncFunctionPrototype.cpp:
2102         * runtime/AtomicsObject.cpp:
2103         * runtime/BooleanConstructor.cpp:
2104         * runtime/BooleanObject.cpp:
2105         * runtime/BooleanPrototype.cpp:
2106         * runtime/ClassInfo.cpp: Copied from Source/JavaScriptCore/tools/JSDollarVM.cpp.
2107         (JSC::ClassInfo::dump):
2108         * runtime/ClassInfo.h:
2109         (JSC::ClassInfo::offsetOfParentClass):
2110         * runtime/ClonedArguments.cpp:
2111         * runtime/ConsoleObject.cpp:
2112         * runtime/CustomGetterSetter.cpp:
2113         * runtime/DateConstructor.cpp:
2114         * runtime/DateInstance.cpp:
2115         * runtime/DatePrototype.cpp:
2116         * runtime/DirectArguments.cpp:
2117         * runtime/Error.cpp:
2118         * runtime/ErrorConstructor.cpp:
2119         * runtime/ErrorInstance.cpp:
2120         * runtime/ErrorPrototype.cpp:
2121         * runtime/EvalExecutable.cpp:
2122         * runtime/Exception.cpp:
2123         * runtime/ExceptionHelpers.cpp:
2124         * runtime/ExecutableBase.cpp:
2125         * runtime/FunctionConstructor.cpp:
2126         * runtime/FunctionExecutable.cpp:
2127         * runtime/FunctionPrototype.cpp:
2128         * runtime/FunctionRareData.cpp:
2129         * runtime/GeneratorFunctionConstructor.cpp:
2130         * runtime/GeneratorFunctionPrototype.cpp:
2131         * runtime/GeneratorPrototype.cpp:
2132         * runtime/GetterSetter.cpp:
2133         * runtime/HashMapImpl.cpp:
2134         * runtime/HashMapImpl.h:
2135         * runtime/InferredType.cpp:
2136         (JSC::InferredType::create):
2137         * runtime/InferredTypeTable.cpp:
2138         * runtime/InferredValue.cpp:
2139         * runtime/InspectorInstrumentationObject.cpp:
2140         * runtime/InternalFunction.cpp:
2141         * runtime/IntlCollator.cpp:
2142         * runtime/IntlCollatorConstructor.cpp:
2143         * runtime/IntlCollatorPrototype.cpp:
2144         * runtime/IntlDateTimeFormat.cpp:
2145         * runtime/IntlDateTimeFormatConstructor.cpp:
2146         * runtime/IntlDateTimeFormatPrototype.cpp:
2147         * runtime/IntlNumberFormat.cpp:
2148         * runtime/IntlNumberFormatConstructor.cpp:
2149         * runtime/IntlNumberFormatPrototype.cpp:
2150         * runtime/IntlObject.cpp:
2151         * runtime/IteratorPrototype.cpp:
2152         * runtime/JSAPIValueWrapper.cpp:
2153         * runtime/JSArray.cpp:
2154         * runtime/JSArrayBuffer.cpp:
2155         * runtime/JSArrayBufferConstructor.cpp:
2156         * runtime/JSArrayBufferPrototype.cpp:
2157         * runtime/JSArrayBufferView.cpp:
2158         * runtime/JSAsyncFunction.cpp:
2159         * runtime/JSBoundFunction.cpp:
2160         * runtime/JSCallee.cpp:
2161         * runtime/JSCustomGetterSetterFunction.cpp:
2162         * runtime/JSDataView.cpp:
2163         * runtime/JSDataViewPrototype.cpp:
2164         * runtime/JSEnvironmentRecord.cpp:
2165         * runtime/JSFixedArray.cpp:
2166         * runtime/JSFunction.cpp:
2167         * runtime/JSGeneratorFunction.cpp:
2168         * runtime/JSGlobalLexicalEnvironment.cpp:
2169         * runtime/JSGlobalObject.cpp:
2170         * runtime/JSInternalPromise.cpp:
2171         * runtime/JSInternalPromiseConstructor.cpp:
2172         * runtime/JSInternalPromiseDeferred.cpp:
2173         * runtime/JSInternalPromisePrototype.cpp:
2174         * runtime/JSLexicalEnvironment.cpp:
2175         * runtime/JSMap.cpp:
2176         * runtime/JSMapIterator.cpp:
2177         * runtime/JSModuleEnvironment.cpp:
2178         * runtime/JSModuleLoader.cpp:
2179         * runtime/JSModuleNamespaceObject.cpp:
2180         * runtime/JSModuleRecord.cpp:
2181         * runtime/JSNativeStdFunction.cpp:
2182         * runtime/JSONObject.cpp:
2183         * runtime/JSObject.cpp:
2184         * runtime/JSPromise.cpp:
2185         * runtime/JSPromiseConstructor.cpp:
2186         * runtime/JSPromiseDeferred.cpp:
2187         * runtime/JSPromisePrototype.cpp:
2188         * runtime/JSPropertyNameEnumerator.cpp:
2189         * runtime/JSPropertyNameIterator.cpp:
2190         * runtime/JSProxy.cpp:
2191         * runtime/JSScriptFetcher.cpp:
2192         * runtime/JSSet.cpp:
2193         * runtime/JSSetIterator.cpp:
2194         * runtime/JSSourceCode.cpp:
2195         * runtime/JSString.cpp:
2196         * runtime/JSStringIterator.cpp:
2197         * runtime/JSSymbolTableObject.cpp:
2198         * runtime/JSTemplateRegistryKey.cpp:
2199         * runtime/JSTypedArrayConstructors.cpp:
2200         * runtime/JSTypedArrayPrototypes.cpp:
2201         * runtime/JSTypedArrayViewConstructor.cpp:
2202         * runtime/JSTypedArrays.cpp:
2203         * runtime/JSWeakMap.cpp:
2204         * runtime/JSWeakSet.cpp:
2205         * runtime/JSWithScope.cpp:
2206         * runtime/MapConstructor.cpp:
2207         * runtime/MapIteratorPrototype.cpp:
2208         * runtime/MapPrototype.cpp:
2209         * runtime/MathObject.cpp:
2210         * runtime/ModuleLoaderPrototype.cpp:
2211         * runtime/ModuleProgramExecutable.cpp:
2212         * runtime/NativeErrorConstructor.cpp:
2213         * runtime/NativeExecutable.cpp:
2214         * runtime/NativeStdFunctionCell.cpp:
2215         * runtime/NullGetterFunction.cpp:
2216         * runtime/NullSetterFunction.cpp:
2217         * runtime/NumberConstructor.cpp:
2218         * runtime/NumberObject.cpp:
2219         * runtime/NumberPrototype.cpp:
2220         * runtime/ObjectConstructor.cpp:
2221         * runtime/ObjectPrototype.cpp:
2222         * runtime/ProgramExecutable.cpp:
2223         * runtime/PropertyTable.cpp:
2224         * runtime/ProxyConstructor.cpp:
2225         * runtime/ProxyObject.cpp:
2226         * runtime/ProxyRevoke.cpp:
2227         * runtime/ReflectObject.cpp:
2228         * runtime/RegExp.cpp:
2229         * runtime/RegExpConstructor.cpp:
2230         * runtime/RegExpObject.cpp:
2231         * runtime/RegExpPrototype.cpp:
2232         * runtime/ScopedArguments.cpp:
2233         * runtime/ScopedArgumentsTable.cpp:
2234         * runtime/ScriptExecutable.cpp:
2235         * runtime/SetConstructor.cpp:
2236         * runtime/SetIteratorPrototype.cpp:
2237         * runtime/SetPrototype.cpp:
2238         * runtime/SparseArrayValueMap.cpp:
2239         * runtime/StrictEvalActivation.cpp:
2240         * runtime/StringConstructor.cpp:
2241         * runtime/StringIteratorPrototype.cpp:
2242         * runtime/StringObject.cpp:
2243         * runtime/StringPrototype.cpp:
2244         * runtime/Structure.cpp:
2245         * runtime/StructureChain.cpp:
2246         * runtime/StructureRareData.cpp:
2247         * runtime/Symbol.cpp:
2248         * runtime/SymbolConstructor.cpp:
2249         * runtime/SymbolObject.cpp:
2250         * runtime/SymbolPrototype.cpp:
2251         * runtime/SymbolTable.cpp:
2252         * runtime/WeakMapConstructor.cpp:
2253         * runtime/WeakMapData.cpp:
2254         * runtime/WeakMapPrototype.cpp:
2255         * runtime/WeakSetConstructor.cpp:
2256         * runtime/WeakSetPrototype.cpp:
2257         * testRegExp.cpp:
2258         * tools/JSDollarVM.cpp:
2259         * tools/JSDollarVMPrototype.cpp:
2260         * wasm/JSWebAssembly.cpp:
2261         * wasm/js/JSWebAssemblyCodeBlock.cpp:
2262         * wasm/js/JSWebAssemblyCompileError.cpp:
2263         * wasm/js/JSWebAssemblyInstance.cpp:
2264         * wasm/js/JSWebAssemblyLinkError.cpp:
2265         * wasm/js/JSWebAssemblyMemory.cpp:
2266         * wasm/js/JSWebAssemblyModule.cpp:
2267         * wasm/js/JSWebAssemblyRuntimeError.cpp:
2268         * wasm/js/JSWebAssemblyTable.cpp:
2269         * wasm/js/WebAssemblyCompileErrorConstructor.cpp:
2270         * wasm/js/WebAssemblyCompileErrorPrototype.cpp:
2271         * wasm/js/WebAssemblyFunction.cpp:
2272         * wasm/js/WebAssemblyFunctionBase.cpp:
2273         * wasm/js/WebAssemblyInstanceConstructor.cpp:
2274         * wasm/js/WebAssemblyInstancePrototype.cpp:
2275         * wasm/js/WebAssemblyLinkErrorConstructor.cpp:
2276         * wasm/js/WebAssemblyLinkErrorPrototype.cpp:
2277         * wasm/js/WebAssemblyMemoryConstructor.cpp:
2278         * wasm/js/WebAssemblyMemoryPrototype.cpp:
2279         * wasm/js/WebAssemblyModuleConstructor.cpp:
2280         * wasm/js/WebAssemblyModulePrototype.cpp:
2281         * wasm/js/WebAssemblyModuleRecord.cpp:
2282         * wasm/js/WebAssemblyPrototype.cpp:
2283         * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
2284         * wasm/js/WebAssemblyRuntimeErrorPrototype.cpp:
2285         * wasm/js/WebAssemblyTableConstructor.cpp:
2286         * wasm/js/WebAssemblyTablePrototype.cpp:
2287         * wasm/js/WebAssemblyToJSCallee.cpp:
2288         * wasm/js/WebAssemblyWrapperFunction.cpp:
2289
2290 2017-05-18  JF Bastien  <jfbastien@apple.com>
2291
2292         WebAssembly: exports is a getter
2293         https://bugs.webkit.org/show_bug.cgi?id=172129
2294
2295         Reviewed by Saam Barati.
2296
2297         As updated here: https://github.com/WebAssembly/design/pull/1062
2298
2299         * wasm/js/JSWebAssemblyInstance.cpp:
2300         (JSC::JSWebAssemblyInstance::finishCreation): don't putDirect here anymore
2301         * wasm/js/JSWebAssemblyInstance.h:
2302         (JSC::JSWebAssemblyInstance::moduleNamespaceObject): add accessor
2303         * wasm/js/WebAssemblyFunctionBase.cpp: squelch causing a warning
2304         * wasm/js/WebAssemblyInstancePrototype.cpp: use LUT
2305         (JSC::getInstance): helper, as in surrounding files
2306         (JSC::webAssemblyInstanceProtoFuncExports): instead of putDirect
2307         * wasm/js/WebAssemblyMemoryPrototype.cpp: pass VM around as for Table
2308         (JSC::getMemory):
2309         (JSC::webAssemblyMemoryProtoFuncGrow):
2310         (JSC::webAssemblyMemoryProtoFuncBuffer):
2311         * wasm/js/WebAssemblyTablePrototype.cpp: static everywhere as with other code
2312         (JSC::webAssemblyTableProtoFuncLength):
2313         (JSC::webAssemblyTableProtoFuncGrow):
2314         (JSC::webAssemblyTableProtoFuncGet):
2315         (JSC::webAssemblyTableProtoFuncSet):
2316
2317 2017-05-18  Saam Barati  <sbarati@apple.com>
2318
2319         Proxy's [[Get]] passes incorrect receiver
2320         https://bugs.webkit.org/show_bug.cgi?id=164849
2321         <rdar://problem/31767058>
2322
2323         Reviewed by Yusuke Suzuki.
2324
2325         * runtime/ProxyObject.cpp:
2326         (JSC::performProxyGet):
2327
2328 2017-05-18  Andy Estes  <aestes@apple.com>
2329
2330         ENABLE(APPLE_PAY_DELEGATE) should be NO on macOS Sierra and earlier
2331         https://bugs.webkit.org/show_bug.cgi?id=172305
2332
2333         Reviewed by Anders Carlsson.
2334
2335         * Configurations/FeatureDefines.xcconfig:
2336
2337 2017-05-18  Saam Barati  <sbarati@apple.com>
2338
2339         We need to destroy worker threads in jsc.cpp
2340         https://bugs.webkit.org/show_bug.cgi?id=170751
2341         <rdar://problem/31800412>
2342
2343         Reviewed by Filip Pizlo.
2344
2345         This patch fixes a bug where a $ agent worker would still
2346         have compilation threads running after the thread the worker
2347         was created on dies. This manifested itself inside DFG AI where
2348         we would notice a string constant is atomic, then the worker
2349         thread would die, destroying its atomic string table, then
2350         we'd notice the same string is no longer atomic, and we'd crash
2351         because we'd fail to see the same speculated type for the same
2352         JSValue.
2353         
2354         This patch makes it so that $ agent workers destroy their VM when
2355         they're done executing. Before a VM gets destroyed, it ensures that
2356         all its compilation threads finish.
2357
2358         * jsc.cpp:
2359         (functionDollarAgentStart):
2360         (runJSC):
2361         (jscmain):
2362
2363 2017-05-18  Michael Saboff  <msaboff@apple.com>
2364
2365         Add FTL whitelist debugging option
2366         https://bugs.webkit.org/show_bug.cgi?id=172321
2367
2368         Reviewed by Saam Barati.
2369
2370         * dfg/DFGTierUpCheckInjectionPhase.cpp:
2371         (JSC::DFG::ensureGlobalFTLWhitelist):
2372         (JSC::DFG::TierUpCheckInjectionPhase::run):
2373         * runtime/Options.h:
2374         * tools/FunctionWhitelist.cpp:
2375         (JSC::FunctionWhitelist::contains):
2376
2377 2017-05-18  Filip Pizlo  <fpizlo@apple.com>
2378
2379         Constructor calls set this too early
2380         https://bugs.webkit.org/show_bug.cgi?id=172302
2381
2382         Reviewed by Saam Barati.
2383         
2384         We were setting this before evaluating the arguments, so this code:
2385         
2386             var x = 42;
2387             new x(x = function() { });
2388         
2389         Would crash because we would pass 42 as this, and create_this would treat it as a cell.
2390         Dereferencing a non-cell is guaranteed to crash.
2391
2392         * bytecompiler/BytecodeGenerator.cpp:
2393         (JSC::BytecodeGenerator::emitConstruct):
2394         * bytecompiler/BytecodeGenerator.h:
2395         * bytecompiler/NodesCodegen.cpp:
2396         (JSC::NewExprNode::emitBytecode):
2397         (JSC::FunctionCallValueNode::emitBytecode):
2398
2399 2017-05-18  Saam Barati  <sbarati@apple.com>
2400
2401         WebAssembly: perform stack checks
2402         https://bugs.webkit.org/show_bug.cgi?id=165546
2403         <rdar://problem/29760307>
2404
2405         Reviewed by Filip Pizlo.
2406
2407         This patch adds stack checks to wasm. It implements it by storing the stack
2408         bounds on the Context.
2409         
2410         Stack checking works as normal, except we do a small optimization for terminal
2411         nodes in the call tree (nodes that don't make any calls). These nodes will
2412         only do a stack check if their frame size is beyond 1024 bytes. Otherwise,
2413         it's assumed the parent that called them did their stack check for them.
2414         This is because all things that make calls make sure to do an extra 1024
2415         bytes whenever doing a stack check.
2416         
2417         We also take into account stack size for potential JS calls when doing
2418         stack checks since our JS stubs don't do this on their own. Each frame
2419         will ensure it does a stack check large enough for any potential JS call
2420         stubs it'll execute.
2421         
2422         Surprisingly, this patch is neutral on WasmBench and TitzerBench.
2423
2424         * llint/LLIntData.cpp:
2425         (JSC::LLInt::Data::performAssertions):
2426         * llint/LowLevelInterpreter.asm:
2427         * runtime/Error.cpp:
2428         (JSC::createRangeError):
2429         (JSC::addErrorInfoAndGetBytecodeOffset):
2430         I fixed a bug here where we assumed that the first frame that has line
2431         and column info would be in our stack trace. This is not correct
2432         since we limit our stack trace size. If everything in our limited
2433         size stack trace is Wasm, then we won't have any frames with line
2434         and column info.
2435         * runtime/Error.h:
2436         * runtime/ExceptionHelpers.cpp:
2437         (JSC::createStackOverflowError):
2438         * runtime/ExceptionHelpers.h:
2439         * runtime/JSGlobalObject.cpp:
2440         (JSC::JSGlobalObject::init):
2441         (JSC::JSGlobalObject::visitChildren):
2442         * runtime/JSGlobalObject.h:
2443         (JSC::JSGlobalObject::webAssemblyToJSCalleeStructure):
2444         * runtime/JSType.h:
2445         * runtime/Options.h: I've added a new option that controls
2446         whether or not we use fast TLS for the wasm context.
2447         * runtime/VM.cpp:
2448         (JSC::VM::VM):
2449         * runtime/VM.h:
2450         * wasm/WasmB3IRGenerator.cpp:
2451         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
2452         * wasm/WasmBinding.cpp:
2453         (JSC::Wasm::wasmToWasm):
2454         * wasm/WasmContext.cpp:
2455         (JSC::Wasm::loadContext):
2456         (JSC::Wasm::storeContext):
2457         * wasm/WasmContext.h:
2458         (JSC::Wasm::useFastTLSForContext):
2459         * wasm/WasmExceptionType.h:
2460         * wasm/WasmMemoryInformation.h:
2461         (JSC::Wasm::PinnedRegisterInfo::toSave):
2462         * wasm/WasmThunks.cpp:
2463         (JSC::Wasm::throwExceptionFromWasmThunkGenerator):
2464         (JSC::Wasm::throwStackOverflowFromWasmThunkGenerator):
2465         (JSC::Wasm::Thunks::stub):
2466         * wasm/WasmThunks.h:
2467         * wasm/js/JSWebAssemblyInstance.h:
2468         (JSC::JSWebAssemblyInstance::offsetOfCachedStackLimit):
2469         (JSC::JSWebAssemblyInstance::cachedStackLimit):
2470         (JSC::JSWebAssemblyInstance::setCachedStackLimit):
2471         * wasm/js/JSWebAssemblyModule.cpp:
2472         (JSC::JSWebAssemblyModule::finishCreation):
2473         * wasm/js/WebAssemblyFunction.cpp:
2474         (JSC::callWebAssemblyFunction):
2475         * wasm/js/WebAssemblyToJSCallee.cpp: Make this a descendent of object.
2476         This is needed for correctness because we may call into JS,
2477         and then the first JS frame could stack overflow. When it stack
2478         overflows, it rolls back one frame to the wasm->js call stub with
2479         the wasm->js callee. It gets the lexical global object from this
2480         frame, meaning it gets the global object from the callee. Therefore,
2481         we must make it an object since all objects have global objects.
2482         (JSC::WebAssemblyToJSCallee::create):
2483         * wasm/js/WebAssemblyToJSCallee.h:
2484
2485 2017-05-18  Keith Miller  <keith_miller@apple.com>
2486
2487         WebAssembly API: test with neutered inputs
2488         https://bugs.webkit.org/show_bug.cgi?id=163899
2489
2490         Reviewed by JF Bastien.
2491
2492         Add tests to check that we properly throw a type error when
2493         we get a transferred ArrayBuffer. Also, we should make sure
2494         we cannot post message a wasm memory's ArrayBuffer.
2495
2496         * API/JSTypedArray.cpp:
2497         (JSObjectGetArrayBufferBytesPtr):
2498         * runtime/ArrayBuffer.cpp:
2499         (JSC::ArrayBuffer::makeShared):
2500         (JSC::ArrayBuffer::makeWasmMemory):
2501         (JSC::ArrayBuffer::transferTo):
2502         (JSC::ArrayBuffer::neuter):
2503         (JSC::ArrayBuffer::notifyIncommingReferencesOfTransfer):
2504         (JSC::errorMesasgeForTransfer):
2505         * runtime/ArrayBuffer.h:
2506         (JSC::ArrayBuffer::isLocked):
2507         (JSC::ArrayBuffer::isWasmMemory):
2508         * wasm/js/JSWebAssemblyMemory.cpp:
2509         (JSC::JSWebAssemblyMemory::buffer):
2510         (JSC::JSWebAssemblyMemory::grow):
2511
2512 2017-05-18  Joseph Pecoraro  <pecoraro@apple.com>
2513
2514         Remote Inspector: Be stricter about checking message types
2515         https://bugs.webkit.org/show_bug.cgi?id=172259
2516         <rdar://problem/32264839>
2517
2518         Reviewed by Brian Burg.
2519
2520         * inspector/remote/cocoa/RemoteInspectorCocoa.mm:
2521         (Inspector::RemoteInspector::receivedSetupMessage):
2522         (Inspector::RemoteInspector::receivedDataMessage):
2523         (Inspector::RemoteInspector::receivedDidCloseMessage):
2524         (Inspector::RemoteInspector::receivedIndicateMessage):
2525         (Inspector::RemoteInspector::receivedConnectionDiedMessage):
2526         (Inspector::RemoteInspector::receivedAutomaticInspectionConfigurationMessage):
2527         (Inspector::RemoteInspector::receivedAutomaticInspectionRejectMessage):
2528         (Inspector::RemoteInspector::receivedAutomationSessionRequestMessage):
2529         * inspector/remote/cocoa/RemoteInspectorXPCConnection.mm:
2530         (Inspector::RemoteInspectorXPCConnection::deserializeMessage):
2531         (Inspector::RemoteInspectorXPCConnection::handleEvent):
2532         (Inspector::RemoteInspectorXPCConnection::sendMessage):
2533         Bail if we don't receive the expected types for message data.
2534
2535 2017-05-18  Filip Pizlo  <fpizlo@apple.com>
2536
2537         DFG inlining should be hardened for the no-result case
2538         https://bugs.webkit.org/show_bug.cgi?id=172290
2539
2540         Reviewed by Saam Barati.
2541         
2542         Previously, if we were inlining a setter call, we might have a bad time because the setter's
2543         result register is the invalid VirtualRegister(), and much of the intrinsic handling code
2544         assumes that the result register is valid.
2545         
2546         This doesn't usually cause problems because people don't usually point a setter at something
2547         that we recognize as an intrinsic.
2548         
2549         * CMakeLists.txt:
2550         * JavaScriptCore.xcodeproj/project.pbxproj:
2551         * b3/air/AirAllocateRegistersAndStackByLinearScan.cpp: Fix a comment.
2552         * dfg/DFGByteCodeParser.cpp: Make RELEASE_ASSERT give accurate stacks. I was getting an absurd stack from the assert I added in DelayedSetLocal.
2553         (JSC::DFG::ByteCodeParser::DelayedSetLocal::DelayedSetLocal): Assert so we catch the problem sooner.
2554         (JSC::DFG::ByteCodeParser::handleIntrinsicCall): Fix the bug.
2555         (JSC::DFG::ByteCodeParser::handleConstantInternalFunction): Fix the bug if constant internal functions were setter-inlineable (they ain't, because the bytecode parser doesn't fold GetSetter).
2556         * runtime/Intrinsic.cpp: Added. I needed this to debug.
2557         (JSC::intrinsicName):
2558         (WTF::printInternal):
2559         * runtime/Intrinsic.h:
2560
2561 2017-05-18  Commit Queue  <commit-queue@webkit.org>
2562
2563         Unreviewed, rolling out r217031, r217032, and r217037.
2564         https://bugs.webkit.org/show_bug.cgi?id=172293
2565
2566         cause linking errors in Windows (Requested by yusukesuzuki on
2567         #webkit).
2568
2569         Reverted changesets:
2570
2571         "[JSC][DFG][DOMJIT] Extend CheckDOM to CheckSubClass"
2572         https://bugs.webkit.org/show_bug.cgi?id=172098
2573         http://trac.webkit.org/changeset/217031
2574
2575         "Unreviewed, rebaseline for newly added ClassInfo"
2576         https://bugs.webkit.org/show_bug.cgi?id=172098
2577         http://trac.webkit.org/changeset/217032
2578
2579         "Unreviewed, fix debug and non-JIT build"
2580         https://bugs.webkit.org/show_bug.cgi?id=172098
2581         http://trac.webkit.org/changeset/217037
2582
2583 2017-05-17  Yusuke Suzuki  <utatane.tea@gmail.com>
2584
2585         Unreviewed, fix debug and non-JIT build
2586         https://bugs.webkit.org/show_bug.cgi?id=172098
2587
2588         * jsc.cpp:
2589         (WTF::DOMJITFunctionObject::checkSubClassPatchpoint):
2590
2591 2017-05-17  Yusuke Suzuki  <utatane.tea@gmail.com>
2592
2593         Unreviewed, rebaseline for newly added ClassInfo
2594         https://bugs.webkit.org/show_bug.cgi?id=172098
2595
2596         * wasm/js/WebAssemblyFunctionBase.cpp:
2597
2598 2017-05-16  Yusuke Suzuki  <utatane.tea@gmail.com>
2599
2600         [JSC][DFG][DOMJIT] Extend CheckDOM to CheckSubClass
2601         https://bugs.webkit.org/show_bug.cgi?id=172098
2602
2603         Reviewed by Saam Barati.
2604
2605         In this patch, we generalize CheckDOM to CheckSubClass.
2606         It can accept any ClassInfo and perform ClassInfo check
2607         in DFG / FTL. Now, we add a new function pointer to ClassInfo,
2608         checkSubClassPatchpoint. It can create DOMJIT patchpoint
2609         for that ClassInfo. It it natural that ClassInfo holds the
2610         way to emit DOMJIT::Patchpoint to perform CheckSubClass
2611         rather than having it in each DOMJIT getter / function
2612         signature annotation.
2613
2614         One problem is that it enlarges the size of ClassInfo.
2615         But this is the best place to put this function pointer.
2616         By doing so, we can add a patchpoint for CheckSubClass
2617         in an non-intrusive manner: WebCore can inject patchpoints
2618         without interactive JSC.
2619
2620         We still have a way to reduce the size of ClassInfo if
2621         we move ArrayBuffer related methods out to the other places.
2622
2623         This patch touches many files because we add a new function
2624         pointer to ClassInfo. But they are basically mechanical change.
2625
2626         * API/JSAPIWrapperObject.mm:
2627         * API/JSCallbackConstructor.cpp:
2628         * API/JSCallbackFunction.cpp:
2629         * API/JSCallbackObject.cpp:
2630         * API/ObjCCallbackFunction.mm:
2631         * CMakeLists.txt:
2632         * JavaScriptCore.xcodeproj/project.pbxproj:
2633         * bytecode/CodeBlock.cpp:
2634         * bytecode/DOMJITAccessCasePatchpointParams.h:
2635         (JSC::DOMJITAccessCasePatchpointParams::DOMJITAccessCasePatchpointParams):
2636         * bytecode/EvalCodeBlock.cpp:
2637         * bytecode/FunctionCodeBlock.cpp:
2638         * bytecode/GetterSetterAccessCase.cpp:
2639         (JSC::GetterSetterAccessCase::emitDOMJITGetter):
2640         * bytecode/ModuleProgramCodeBlock.cpp:
2641         * bytecode/ProgramCodeBlock.cpp:
2642         * bytecode/UnlinkedCodeBlock.cpp:
2643         * bytecode/UnlinkedEvalCodeBlock.cpp:
2644         * bytecode/UnlinkedFunctionCodeBlock.cpp:
2645         * bytecode/UnlinkedFunctionExecutable.cpp:
2646         * bytecode/UnlinkedModuleProgramCodeBlock.cpp:
2647         * bytecode/UnlinkedProgramCodeBlock.cpp:
2648         * debugger/DebuggerScope.cpp:
2649         * dfg/DFGAbstractInterpreterInlines.h:
2650         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2651         * dfg/DFGByteCodeParser.cpp:
2652         (JSC::DFG::ByteCodeParser::handleDOMJITGetter):
2653         * dfg/DFGClobberize.h:
2654         (JSC::DFG::clobberize):
2655         * dfg/DFGConstantFoldingPhase.cpp:
2656         (JSC::DFG::ConstantFoldingPhase::foldConstants):
2657         * dfg/DFGDOMJITPatchpointParams.h:
2658         (JSC::DFG::DOMJITPatchpointParams::DOMJITPatchpointParams):
2659         * dfg/DFGDoesGC.cpp:
2660         (JSC::DFG::doesGC):
2661         * dfg/DFGFixupPhase.cpp:
2662         (JSC::DFG::FixupPhase::fixupNode):
2663         (JSC::DFG::FixupPhase::attemptToMakeCallDOM):
2664         (JSC::DFG::FixupPhase::fixupCheckSubClass):
2665         (JSC::DFG::FixupPhase::fixupCheckDOM): Deleted.
2666         * dfg/DFGGraph.cpp:
2667         (JSC::DFG::Graph::dump):
2668         * dfg/DFGNode.h:
2669         (JSC::DFG::Node::hasClassInfo):
2670         (JSC::DFG::Node::classInfo):
2671         (JSC::DFG::Node::hasCheckDOMPatchpoint): Deleted.
2672         (JSC::DFG::Node::checkDOMPatchpoint): Deleted.
2673         * dfg/DFGNodeType.h:
2674         * dfg/DFGPredictionPropagationPhase.cpp:
2675         * dfg/DFGSafeToExecute.h:
2676         (JSC::DFG::safeToExecute):
2677         * dfg/DFGSpeculativeJIT.cpp:
2678         (JSC::DFG::SpeculativeJIT::compileCheckSubClass):
2679         (JSC::DFG::SpeculativeJIT::compileCheckDOM): Deleted.
2680         * dfg/DFGSpeculativeJIT.h:
2681         (JSC::DFG::SpeculativeJIT::vm):
2682         * dfg/DFGSpeculativeJIT32_64.cpp:
2683         (JSC::DFG::SpeculativeJIT::compile):
2684         In DFG, we rename CheckDOM to CheckSubClass. It just holds ClassInfo.
2685         And ClassInfo knows how to perform CheckSubClass efficiently.
2686         If ClassInfo does not have a way to perform CheckSubClass efficiently,
2687         we just perform jsDynamicCast thing in ASM.
2688         * dfg/DFGSpeculativeJIT64.cpp:
2689         (JSC::DFG::SpeculativeJIT::compile):
2690         * domjit/DOMJITGetterSetter.h:
2691         * domjit/DOMJITPatchpointParams.h:
2692         (JSC::DOMJIT::PatchpointParams::PatchpointParams):
2693         (JSC::DOMJIT::PatchpointParams::vm):
2694         * domjit/DOMJITSignature.h:
2695         (JSC::DOMJIT::Signature::Signature):
2696         (JSC::DOMJIT::Signature::checkDOM): Deleted.
2697         * ftl/FTLAbstractHeapRepository.h:
2698         * ftl/FTLCapabilities.cpp:
2699         (JSC::FTL::canCompile):
2700         * ftl/FTLDOMJITPatchpointParams.h:
2701         (JSC::FTL::DOMJITPatchpointParams::DOMJITPatchpointParams):
2702         * ftl/FTLLowerDFGToB3.cpp:
2703         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2704         (JSC::FTL::DFG::LowerDFGToB3::compileCheckSubClass):
2705         (JSC::FTL::DFG::LowerDFGToB3::compileCheckDOM): Deleted.
2706         * inspector/JSInjectedScriptHost.cpp:
2707         * inspector/JSInjectedScriptHostPrototype.cpp:
2708         * inspector/JSJavaScriptCallFrame.cpp:
2709         * inspector/JSJavaScriptCallFramePrototype.cpp:
2710         * jsc.cpp:
2711         (WTF::DOMJITNode::checkSubClassPatchpoint):
2712         (WTF::DOMJITFunctionObject::checkSubClassPatchpoint):
2713         (WTF::DOMJITFunctionObject::finishCreation):
2714         (WTF::DOMJITCheckSubClassObject::DOMJITCheckSubClassObject):
2715         (WTF::DOMJITCheckSubClassObject::createStructure):
2716         (WTF::DOMJITCheckSubClassObject::create):
2717         (WTF::DOMJITCheckSubClassObject::safeFunction):
2718         (WTF::DOMJITCheckSubClassObject::unsafeFunction):
2719         (WTF::DOMJITCheckSubClassObject::finishCreation):
2720         (GlobalObject::finishCreation):
2721         (functionCreateDOMJITCheckSubClassObject):
2722         (WTF::DOMJITNode::checkDOMJITNode): Deleted.
2723         (WTF::DOMJITFunctionObject::checkDOMJITNode): Deleted.
2724         * runtime/AbstractModuleRecord.cpp:
2725         * runtime/ArrayBufferNeuteringWatchpoint.cpp:
2726         * runtime/ArrayConstructor.cpp:
2727         * runtime/ArrayIteratorPrototype.cpp:
2728         * runtime/ArrayPrototype.cpp:
2729         * runtime/AsyncFunctionConstructor.cpp:
2730         * runtime/AsyncFunctionPrototype.cpp:
2731         * runtime/AtomicsObject.cpp:
2732         * runtime/BooleanConstructor.cpp:
2733         * runtime/BooleanObject.cpp:
2734         * runtime/BooleanPrototype.cpp:
2735         * runtime/ClassInfo.cpp: Copied from Source/JavaScriptCore/tools/JSDollarVM.cpp.
2736         (JSC::ClassInfo::dump):
2737         * runtime/ClassInfo.h:
2738         (JSC::ClassInfo::offsetOfParentClass):
2739         * runtime/ClonedArguments.cpp:
2740         * runtime/ConsoleObject.cpp:
2741         * runtime/CustomGetterSetter.cpp:
2742         * runtime/DateConstructor.cpp:
2743         * runtime/DateInstance.cpp:
2744         * runtime/DatePrototype.cpp:
2745         * runtime/DirectArguments.cpp:
2746         * runtime/Error.cpp:
2747         * runtime/ErrorConstructor.cpp:
2748         * runtime/ErrorInstance.cpp:
2749         * runtime/ErrorPrototype.cpp:
2750         * runtime/EvalExecutable.cpp:
2751         * runtime/Exception.cpp:
2752         * runtime/ExceptionHelpers.cpp:
2753         * runtime/ExecutableBase.cpp:
2754         * runtime/FunctionConstructor.cpp:
2755         * runtime/FunctionExecutable.cpp:
2756         * runtime/FunctionPrototype.cpp:
2757         * runtime/FunctionRareData.cpp:
2758         * runtime/GeneratorFunctionConstructor.cpp:
2759         * runtime/GeneratorFunctionPrototype.cpp:
2760         * runtime/GeneratorPrototype.cpp:
2761         * runtime/GetterSetter.cpp:
2762         * runtime/HashMapImpl.cpp:
2763         * runtime/HashMapImpl.h:
2764         * runtime/InferredType.cpp:
2765         (JSC::InferredType::create):
2766         * runtime/InferredTypeTable.cpp:
2767         * runtime/InferredValue.cpp:
2768         * runtime/InspectorInstrumentationObject.cpp:
2769         * runtime/InternalFunction.cpp:
2770         * runtime/IntlCollator.cpp:
2771         * runtime/IntlCollatorConstructor.cpp:
2772         * runtime/IntlCollatorPrototype.cpp:
2773         * runtime/IntlDateTimeFormat.cpp:
2774         * runtime/IntlDateTimeFormatConstructor.cpp:
2775         * runtime/IntlDateTimeFormatPrototype.cpp:
2776         * runtime/IntlNumberFormat.cpp:
2777         * runtime/IntlNumberFormatConstructor.cpp:
2778         * runtime/IntlNumberFormatPrototype.cpp:
2779         * runtime/IntlObject.cpp:
2780         * runtime/IteratorPrototype.cpp:
2781         * runtime/JSAPIValueWrapper.cpp:
2782         * runtime/JSArray.cpp:
2783         * runtime/JSArrayBuffer.cpp:
2784         * runtime/JSArrayBufferConstructor.cpp:
2785         * runtime/JSArrayBufferPrototype.cpp:
2786         * runtime/JSArrayBufferView.cpp:
2787         * runtime/JSAsyncFunction.cpp:
2788         * runtime/JSBoundFunction.cpp:
2789         * runtime/JSCallee.cpp:
2790         * runtime/JSCustomGetterSetterFunction.cpp:
2791         * runtime/JSDataView.cpp:
2792         * runtime/JSDataViewPrototype.cpp:
2793         * runtime/JSEnvironmentRecord.cpp:
2794         * runtime/JSFixedArray.cpp:
2795         * runtime/JSFunction.cpp:
2796         * runtime/JSGeneratorFunction.cpp:
2797         * runtime/JSGlobalLexicalEnvironment.cpp:
2798         * runtime/JSGlobalObject.cpp:
2799         * runtime/JSInternalPromise.cpp:
2800         * runtime/JSInternalPromiseConstructor.cpp:
2801         * runtime/JSInternalPromiseDeferred.cpp:
2802         * runtime/JSInternalPromisePrototype.cpp:
2803         * runtime/JSLexicalEnvironment.cpp:
2804         * runtime/JSMap.cpp:
2805         * runtime/JSMapIterator.cpp:
2806         * runtime/JSModuleEnvironment.cpp:
2807         * runtime/JSModuleLoader.cpp:
2808         * runtime/JSModuleNamespaceObject.cpp:
2809         * runtime/JSModuleRecord.cpp:
2810         * runtime/JSNativeStdFunction.cpp:
2811         * runtime/JSONObject.cpp:
2812         * runtime/JSObject.cpp:
2813         * runtime/JSPromise.cpp:
2814         * runtime/JSPromiseConstructor.cpp:
2815         * runtime/JSPromiseDeferred.cpp:
2816         * runtime/JSPromisePrototype.cpp:
2817         * runtime/JSPropertyNameEnumerator.cpp:
2818         * runtime/JSPropertyNameIterator.cpp:
2819         * runtime/JSProxy.cpp:
2820         * runtime/JSScriptFetcher.cpp:
2821         * runtime/JSSet.cpp:
2822         * runtime/JSSetIterator.cpp:
2823         * runtime/JSSourceCode.cpp:
2824         * runtime/JSString.cpp:
2825         * runtime/JSStringIterator.cpp:
2826         * runtime/JSSymbolTableObject.cpp:
2827         * runtime/JSTemplateRegistryKey.cpp:
2828         * runtime/JSTypedArrayConstructors.cpp:
2829         * runtime/JSTypedArrayPrototypes.cpp:
2830         * runtime/JSTypedArrayViewConstructor.cpp:
2831         * runtime/JSTypedArrays.cpp:
2832         * runtime/JSWeakMap.cpp:
2833         * runtime/JSWeakSet.cpp:
2834         * runtime/JSWithScope.cpp:
2835         * runtime/MapConstructor.cpp:
2836         * runtime/MapIteratorPrototype.cpp:
2837         * runtime/MapPrototype.cpp:
2838         * runtime/MathObject.cpp:
2839         * runtime/ModuleLoaderPrototype.cpp:
2840         * runtime/ModuleProgramExecutable.cpp:
2841         * runtime/NativeErrorConstructor.cpp:
2842         * runtime/NativeExecutable.cpp:
2843         * runtime/NativeStdFunctionCell.cpp:
2844         * runtime/NullGetterFunction.cpp:
2845         * runtime/NullSetterFunction.cpp:
2846         * runtime/NumberConstructor.cpp:
2847         * runtime/NumberObject.cpp:
2848         * runtime/NumberPrototype.cpp:
2849         * runtime/ObjectConstructor.cpp:
2850         * runtime/ObjectPrototype.cpp:
2851         * runtime/ProgramExecutable.cpp:
2852         * runtime/PropertyTable.cpp:
2853         * runtime/ProxyConstructor.cpp:
2854         * runtime/ProxyObject.cpp:
2855         * runtime/ProxyRevoke.cpp:
2856         * runtime/ReflectObject.cpp:
2857         * runtime/RegExp.cpp:
2858         * runtime/RegExpConstructor.cpp:
2859         * runtime/RegExpObject.cpp:
2860         * runtime/RegExpPrototype.cpp:
2861         * runtime/ScopedArguments.cpp:
2862         * runtime/ScopedArgumentsTable.cpp:
2863         * runtime/ScriptExecutable.cpp:
2864         * runtime/SetConstructor.cpp:
2865         * runtime/SetIteratorPrototype.cpp:
2866         * runtime/SetPrototype.cpp:
2867         * runtime/SparseArrayValueMap.cpp:
2868         * runtime/StrictEvalActivation.cpp:
2869         * runtime/StringConstructor.cpp:
2870         * runtime/StringIteratorPrototype.cpp:
2871         * runtime/StringObject.cpp:
2872         * runtime/StringPrototype.cpp:
2873         * runtime/Structure.cpp:
2874         * runtime/StructureChain.cpp:
2875         * runtime/StructureRareData.cpp:
2876         * runtime/Symbol.cpp:
2877         * runtime/SymbolConstructor.cpp:
2878         * runtime/SymbolObject.cpp:
2879         * runtime/SymbolPrototype.cpp:
2880         * runtime/SymbolTable.cpp:
2881         * runtime/WeakMapConstructor.cpp:
2882         * runtime/WeakMapData.cpp:
2883         * runtime/WeakMapPrototype.cpp:
2884         * runtime/WeakSetConstructor.cpp:
2885         * runtime/WeakSetPrototype.cpp:
2886         * testRegExp.cpp:
2887         * tools/JSDollarVM.cpp:
2888         * tools/JSDollarVMPrototype.cpp:
2889         * wasm/JSWebAssembly.cpp:
2890         * wasm/js/JSWebAssemblyCodeBlock.cpp:
2891         * wasm/js/JSWebAssemblyCompileError.cpp:
2892         * wasm/js/JSWebAssemblyInstance.cpp:
2893         * wasm/js/JSWebAssemblyLinkError.cpp:
2894         * wasm/js/JSWebAssemblyMemory.cpp:
2895         * wasm/js/JSWebAssemblyModule.cpp:
2896         * wasm/js/JSWebAssemblyRuntimeError.cpp:
2897         * wasm/js/JSWebAssemblyTable.cpp:
2898         * wasm/js/WebAssemblyCompileErrorConstructor.cpp:
2899         * wasm/js/WebAssemblyCompileErrorPrototype.cpp:
2900         * wasm/js/WebAssemblyFunction.cpp:
2901         * wasm/js/WebAssemblyInstanceConstructor.cpp:
2902         * wasm/js/WebAssemblyInstancePrototype.cpp:
2903         * wasm/js/WebAssemblyLinkErrorConstructor.cpp:
2904         * wasm/js/WebAssemblyLinkErrorPrototype.cpp:
2905         * wasm/js/WebAssemblyMemoryConstructor.cpp:
2906         * wasm/js/WebAssemblyMemoryPrototype.cpp:
2907         * wasm/js/WebAssemblyModuleConstructor.cpp:
2908         * wasm/js/WebAssemblyModulePrototype.cpp:
2909         * wasm/js/WebAssemblyModuleRecord.cpp:
2910         * wasm/js/WebAssemblyPrototype.cpp:
2911         * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
2912         * wasm/js/WebAssemblyRuntimeErrorPrototype.cpp:
2913         * wasm/js/WebAssemblyTableConstructor.cpp:
2914         * wasm/js/WebAssemblyTablePrototype.cpp:
2915         * wasm/js/WebAssemblyToJSCallee.cpp:
2916         * wasm/js/WebAssemblyWrapperFunction.cpp:
2917
2918 2017-05-17  Saam Barati  <sbarati@apple.com>
2919
2920         We don't do context switches for Wasm->Wasm call indirect
2921         https://bugs.webkit.org/show_bug.cgi?id=172188
2922         <rdar://problem/32231828>
2923
2924         Reviewed by Keith Miller.
2925
2926         We did not do a context switch when doing an indirect call. 
2927         This is clearly wrong, since the thing we're making an indirect
2928         call to could be from another instance. This patch fixes this
2929         oversight by doing a very simple context switch. I've also opened
2930         a bug to make indirect calls fast: https://bugs.webkit.org/show_bug.cgi?id=172197
2931         since this patch adds yet another branch to the indirect call path.
2932         I've also added tests that either throw or crash before this change.
2933
2934         * CMakeLists.txt:
2935         * JavaScriptCore.xcodeproj/project.pbxproj:
2936         * wasm/WasmB3IRGenerator.cpp:
2937         * wasm/js/JSWebAssemblyTable.h:
2938         (JSC::JSWebAssemblyTable::offsetOfJSFunctions):
2939         * wasm/js/WebAssemblyFunction.cpp:
2940         (JSC::WebAssemblyFunction::visitChildren):
2941         (JSC::WebAssemblyFunction::finishCreation): Deleted.
2942         * wasm/js/WebAssemblyFunction.h:
2943         (JSC::WebAssemblyFunction::instance): Deleted.
2944         (JSC::WebAssemblyFunction::offsetOfInstance): Deleted.
2945         * wasm/js/WebAssemblyFunctionBase.cpp: Added.
2946         (JSC::WebAssemblyFunctionBase::WebAssemblyFunctionBase):
2947         (JSC::WebAssemblyFunctionBase::visitChildren):
2948         (JSC::WebAssemblyFunctionBase::finishCreation):
2949         * wasm/js/WebAssemblyFunctionBase.h: Added.
2950         (JSC::WebAssemblyFunctionBase::instance):
2951         (JSC::WebAssemblyFunctionBase::offsetOfInstance):
2952         * wasm/js/WebAssemblyModuleRecord.cpp:
2953         (JSC::WebAssemblyModuleRecord::link):
2954         (JSC::WebAssemblyModuleRecord::evaluate):
2955         * wasm/js/WebAssemblyWrapperFunction.cpp:
2956         (JSC::WebAssemblyWrapperFunction::create):
2957         (JSC::WebAssemblyWrapperFunction::finishCreation):
2958         (JSC::WebAssemblyWrapperFunction::visitChildren):
2959         * wasm/js/WebAssemblyWrapperFunction.h:
2960
2961 2017-05-17  Filip Pizlo  <fpizlo@apple.com>
2962
2963         JSC: Incorrect LoadVarargs handling in ArgumentsEliminationPhase::transform
2964         https://bugs.webkit.org/show_bug.cgi?id=172208
2965
2966         Reviewed by Saam Barati.
2967
2968         * dfg/DFGArgumentsEliminationPhase.cpp:
2969
2970 2017-05-17  Don Olmstead  <don.olmstead@am.sony.com>
2971
2972         [Win] Support $vm.getpid()
2973         https://bugs.webkit.org/show_bug.cgi?id=172248
2974
2975         Reviewed by Mark Lam.
2976
2977         * tools/JSDollarVMPrototype.cpp:
2978         (JSC::functionGetPID):
2979         (JSC::JSDollarVMPrototype::finishCreation):
2980
2981 2017-05-17  Michael Saboff  <msaboff@apple.com>
2982
2983         [iOS] The Garbage Collector shouldn't rely on the bmalloc scavenger for up to date memory footprint info
2984         https://bugs.webkit.org/show_bug.cgi?id=172186
2985
2986         Reviewed by Geoffrey Garen.
2987
2988         The calls to bmalloc::api::memoryFootprint() and ::percentAvailableMemoryInUse() now call
2989         the OS to get up to date values.  In overCriticalMemoryThreshold(), we get the current value every
2990         100th call and use a cached value the rest of the time.  When colleciton is done, we start with
2991         a new overCriticalMemoryThreshold value for the next cycle.
2992
2993         The choice of 1 out of 100 calls was validated by using JetStream and verifying that it didn't impact
2994         performance and still provides timely memory footprint data.  With additional debug logging, I
2995         determined that we call overCriticalMemoryThreshold() over 20,000 times/second running JetStream.
2996         Other logging showed that there were over 1700 calls to overCriticalMemoryThreshold() on average per
2997         GC cycle.  Dividing both of these numbers by 100 seems reasonable.
2998
2999         * heap/Heap.cpp:
3000         (JSC::Heap::overCriticalMemoryThreshold):
3001         (JSC::Heap::updateAllocationLimits):
3002         (JSC::Heap::shouldDoFullCollection):
3003         * heap/Heap.h:
3004
3005 2017-05-17  Saam Barati  <sbarati@apple.com>
3006
3007         PinnedRegisters should be better modeled in IRC/Briggs
3008         https://bugs.webkit.org/show_bug.cgi?id=171955
3009
3010         Reviewed by Filip Pizlo.
3011
3012         This patch fixes a bug in Briggs/IRC with respect to pinned registers.
3013         Pinned registers were not part of the assignable register file in IRC/Briggs,
3014         and this would lead to an asymmetry because they were modeled in the
3015         interference graph. The bug is that we use registerCount() to move various
3016         Tmps between various lists in the different allocators, and if a Tmp
3017         interfered with a pinned register (usually via a Patchpoint's clobbered set),
3018         we'd have an interference edge modeled in the degree for that Tmp, but the registerCount()
3019         would make us think that this particular Tmp is not assignable. This would
3020         lead us to fail to color a colorable graph. Specifically, this happened in
3021         our various patchpoint tests that stress the register allocator by forcing
3022         the entire register file into arguments for the patchpoint and then doing
3023         interesting things with the result, arguments, etc.
3024         
3025         This patch fixes the bug by coming up with an more natural way to model pinned
3026         registers. Pinned registers are now part of the register file. However,
3027         pinned registers are live at every point in the program (this is a defining
3028         property of a pinned register). In practice, this means that the only Tmps 
3029         that can be assigned to pinned registers are ones that are coalescing
3030         candidates. This means the program has some number of defs for a Tmp T like:
3031         MoveType pinnedReg, T
3032         
3033         Note, if any other defs for T happen, like:
3034         Add32, t1, t2, T
3035         T will have an interference edge with pinnedReg, since pinnedReg is live
3036         at every point in the program. Modeling pinned registers this way allows
3037         IRC/Briggs to have no special casing for them. It treats it like any other
3038         precolored Tmp. This allows us to do coalescing, biased coloring, etc, which
3039         could all lead to a Tmp being assigned to a pinned register.
3040         
3041         Interestingly, we used to have special handling for the frame pointer
3042         register, which in many ways, acts like a pinned register, since FP is
3043         always live, and we wanted it to take place in coalescing. The allocator
3044         had a side-table interference graph with FP. Interestingly, we didn't even
3045         handle this properly everywhere since we could rely on a patchpoint never
3046         claiming to clobber FP (this would be illegal). So the code only handled
3047         the pseudo-pinned register properties of FP in various places. This patch
3048         drops this special casing and pins FP since all pinned registers can take
3049         part in coalescing.
3050
3051         * b3/B3PatchpointSpecial.h:
3052         * b3/B3Procedure.cpp:
3053         (JSC::B3::Procedure::mutableGPRs):
3054         (JSC::B3::Procedure::mutableFPRs):
3055         * b3/B3Procedure.h:
3056         * b3/air/AirAllocateRegistersByGraphColoring.cpp:
3057         * b3/air/AirCode.cpp:
3058         (JSC::B3::Air::Code::Code):
3059         (JSC::B3::Air::Code::pinRegister):
3060         (JSC::B3::Air::Code::mutableGPRs):
3061         (JSC::B3::Air::Code::mutableFPRs):
3062         * b3/air/AirCode.h:
3063         (JSC::B3::Air::Code::pinnedRegisters):
3064         * b3/air/AirSpecial.h:
3065         * b3/air/testair.cpp:
3066         * b3/testb3.cpp:
3067         (JSC::B3::testSimplePatchpointWithOuputClobbersGPArgs):
3068         (JSC::B3::testSpillDefSmallerThanUse):
3069         (JSC::B3::testLateRegister):
3070         (JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled):
3071         (JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled2):
3072         (JSC::B3::testMoveConstants):
3073
3074 2017-05-16  Yusuke Suzuki  <utatane.tea@gmail.com>
3075
3076         [DFG] Constant Folding Phase should convert MakeRope("", String) => Identity(String)
3077         https://bugs.webkit.org/show_bug.cgi?id=172115
3078
3079         Reviewed by Saam Barati.
3080
3081         In Fixup phase, we attempt to fold MakeRope to Identity (or reduce arguments) by dropping
3082         empty strings. However, when we are in Fixup phase, we do not have much information about
3083         constant values.
3084
3085         In ARES-6 Babylon, we find that we can constant-fold MakeRope by using constants figured
3086         out by CFA. Without it, Babylon repeatedly produces rope strings. To fix this, we introduce
3087         MakeRope handling in constant folding phase.
3088
3089         It shows 7.5% performance improvement in ARES-6 Babylon steadyState.
3090
3091             Before:
3092
3093             firstIteration:     50.02 +- 14.56 ms
3094             averageWorstCase:   26.52 +- 4.52 ms
3095             steadyState:        8.15 +- 0.23 ms
3096
3097             After:
3098
3099             firstIteration:     49.08 +- 12.90 ms
3100             averageWorstCase:   25.16 +- 3.82 ms
3101             steadyState:        7.58 +- 0.21 ms
3102
3103         * dfg/DFGAbstractInterpreterInlines.h:
3104         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3105         * dfg/DFGConstantFoldingPhase.cpp:
3106         (JSC::DFG::ConstantFoldingPhase::foldConstants):
3107
3108 2017-05-16  Yusuke Suzuki  <utatane.tea@gmail.com>
3109
3110         Unreviewed, add Objective C files to CMake Mac port
3111         https://bugs.webkit.org/show_bug.cgi?id=172103
3112
3113         * shell/PlatformMac.cmake: Added.
3114
3115 2017-05-16  JF Bastien  <jfbastien@apple.com>
3116
3117         WebAssembly: enforce size limits
3118         https://bugs.webkit.org/show_bug.cgi?id=165833
3119         <rdar://problem/29760219>
3120
3121         Reviewed by Keith Miller.
3122
3123         Use the same limits as V8.
3124
3125         * JavaScriptCore.xcodeproj/project.pbxproj:
3126         * wasm/WasmLimits.h: Added.
3127         * wasm/WasmModuleParser.cpp:
3128         * wasm/WasmParser.h:
3129         (JSC::Wasm::Parser<SuccessType>::consumeUTF8String):
3130
3131 2017-05-15  Yusuke Suzuki  <utatane.tea@gmail.com>
3132
3133         [JSC] Build testapi in non Apple ports
3134         https://bugs.webkit.org/show_bug.cgi?id=172103
3135
3136         Reviewed by Filip Pizlo.
3137
3138         This patch makes JSC testapi buildable in non-Apple ports.
3139         We isolate CF related tests in testapi.c. If we do not use
3140         CF, we include JavaScript.h instead of JavaScriptCore.h.
3141
3142         By running the testapi in Linux, we found that contraints
3143         test have a bug: If constraint marker runs after WeakRefs
3144         are destroyed, it accesses destroyed WeakRef. This patch
3145         also fixes it.
3146
3147         * API/tests/CurrentThisInsideBlockGetterTest.h:
3148         * API/tests/CustomGlobalObjectClassTest.c:
3149         * API/tests/ExecutionTimeLimitTest.cpp:
3150         * API/tests/FunctionOverridesTest.cpp:
3151         * API/tests/GlobalContextWithFinalizerTest.cpp:
3152         * API/tests/JSObjectGetProxyTargetTest.cpp:
3153         * API/tests/MultithreadedMultiVMExecutionTest.cpp:
3154         * API/tests/PingPongStackOverflowTest.cpp:
3155         * API/tests/TypedArrayCTest.cpp:
3156         * API/tests/testapi.c:
3157         (assertEqualsAsCharactersPtr):
3158         (markingConstraint):
3159         (testMarkingConstraintsAndHeapFinalizers):
3160         (testCFStrings):
3161         (main):
3162         * shell/CMakeLists.txt:
3163
3164 2017-05-16  JF Bastien  <jfbastien@apple.com>
3165
3166         WebAssembly: report Memory usage to GC
3167         https://bugs.webkit.org/show_bug.cgi?id=170690
3168         <rdar://problem/31965310>
3169
3170         Reviewed by Keith Miller.
3171
3172         * wasm/js/JSWebAssemblyMemory.cpp:
3173         (JSC::JSWebAssemblyMemory::grow):
3174         (JSC::JSWebAssemblyMemory::finishCreation):
3175         (JSC::JSWebAssemblyMemory::visitChildren):
3176
3177 2017-05-16  JF Bastien  <jfbastien@apple.com>
3178
3179         WebAssembly: validate load / store alignment
3180         https://bugs.webkit.org/show_bug.cgi?id=168836
3181         <rdar://problem/31965349>
3182
3183         Reviewed by Keith Miller.
3184
3185         * wasm/WasmFunctionParser.h: check the alignment
3186         * wasm/generateWasm.py: generate the log2 alignment helper
3187         (Wasm):
3188         (isSimple):
3189         (memoryLog2Alignment):
3190         * wasm/generateWasmOpsHeader.py:
3191         (memoryLog2AlignmentGenerator):
3192         * wasm/wasm.json: fix formatting
3193
3194 2017-05-15  Mark Lam  <mark.lam@apple.com>
3195
3196         Rolling out r214038 and r213697: Crashes when using computed properties with rest destructuring and object spread.
3197         https://bugs.webkit.org/show_bug.cgi?id=172147
3198
3199         Rubber-stamped by Saam Barati.
3200
3201         I rolled out every thing in those 2 patches except for the change to make
3202         CodeBlock::finishCreation() return a bool plus its clients that depend on this.
3203         I made this exception because r214931 relies on this change, and this part of
3204         the change looks correct.
3205
3206         * builtins/BuiltinNames.h:
3207         * builtins/GlobalOperations.js:
3208         (globalPrivate.speciesConstructor):
3209         (globalPrivate.copyDataProperties): Deleted.
3210         * bytecode/CodeBlock.cpp:
3211         (JSC::CodeBlock::finishCreation):
3212         (JSC::CodeBlock::setConstantIdentifierSetRegisters): Deleted.
3213         * bytecode/CodeBlock.h:
3214         * bytecode/UnlinkedCodeBlock.h:
3215         (JSC::UnlinkedCodeBlock::addBitVector):
3216         (JSC::UnlinkedCodeBlock::constantRegisters):
3217         (JSC::UnlinkedCodeBlock::addSetConstant): Deleted.
3218         (JSC::UnlinkedCodeBlock::constantIdentifierSets): Deleted.
3219         * bytecompiler/BytecodeGenerator.cpp:
3220         * bytecompiler/BytecodeGenerator.h:
3221         * bytecompiler/NodesCodegen.cpp:
3222         (JSC::PropertyListNode::emitBytecode):
3223         (JSC::ObjectPatternNode::bindValue):
3224         (JSC::ObjectSpreadExpressionNode::emitBytecode): Deleted.
3225         * parser/ASTBuilder.h:
3226         (JSC::ASTBuilder::createProperty):
3227         (JSC::ASTBuilder::appendObjectPatternEntry):
3228         (JSC::ASTBuilder::createObjectSpreadExpression): Deleted.
3229         (JSC::ASTBuilder::appendObjectPatternRestEntry): Deleted.
3230         (JSC::ASTBuilder::setContainsObjectRestElement): Deleted.
3231         * parser/NodeConstructors.h:
3232         (JSC::PropertyNode::PropertyNode):
3233         (JSC::SpreadExpressionNode::SpreadExpressionNode):
3234         (JSC::ObjectSpreadExpressionNode::ObjectSpreadExpressionNode): Deleted.
3235         * parser/Nodes.h:
3236         (JSC::ObjectPatternNode::appendEntry):
3237         (JSC::ObjectSpreadExpressionNode::expression): Deleted.
3238         (JSC::ObjectPatternNode::setContainsRestElement): Deleted.
3239         * parser/Parser.cpp:
3240         (JSC::Parser<LexerType>::parseDestructuringPattern):
3241         (JSC::Parser<LexerType>::parseProperty):
3242         * parser/SyntaxChecker.h:
3243         (JSC::SyntaxChecker::createSpreadExpression):
3244         (JSC::SyntaxChecker::createProperty):
3245         (JSC::SyntaxChecker::operatorStackPop):
3246         (JSC::SyntaxChecker::createObjectSpreadExpression): Deleted.
3247         * runtime/ObjectConstructor.cpp:
3248         (JSC::ObjectConstructor::finishCreation):
3249         * runtime/SetPrototype.cpp:
3250         (JSC::SetPrototype::finishCreation):
3251
3252 2017-05-15  David Kilzer  <ddkilzer@apple.com>
3253
3254         JSEnvironmentRecord::allocationSizeForScopeSize() and offsetOfVariable(ScopeOffset) should used checked arithmetic
3255         <https://webkit.org/b/172134>
3256
3257         Reviewed by Saam Barati.
3258
3259         * runtime/JSEnvironmentRecord.h:
3260         (JSC::JSEnvironmentRecord::offsetOfVariable): Change to return
3261         size_t and use checked arithmetic.
3262         (JSC::JSEnvironmentRecord::allocationSizeForScopeSize): Change
3263         to use checked arithmetic.
3264
3265 2017-05-15  Mark Lam  <mark.lam@apple.com>
3266
3267         WorkerRunLoop::Task::performTask() should check !scriptController->isTerminatingExecution().
3268         https://bugs.webkit.org/show_bug.cgi?id=171775
3269         <rdar://problem/30975761>
3270
3271         Reviewed by Filip Pizlo.
3272
3273         Increased the number of frames captured in VM::nativeStackTraceOfLastThrow()
3274         from 25 to 100.  From experience, I found that 25 is sometimes not sufficient
3275         for our debugging needs.
3276
3277         Also added VM::throwingThread() to track which thread an exception was thrown in.
3278         This may be useful if the client is entering the VM from different threads.
3279
3280         * runtime/ExceptionScope.cpp:
3281         (JSC::ExceptionScope::unexpectedExceptionMessage):
3282         * runtime/ExceptionScope.h:
3283         (JSC::ExceptionScope::exception):
3284         (JSC::ExceptionScope::unexpectedExceptionMessage):
3285         * runtime/Options.h:
3286         - Added the unexpectedExceptionStackTraceLimit option.
3287         * runtime/VM.cpp:
3288         (JSC::VM::throwException):
3289         * runtime/VM.h:
3290         (JSC::VM::throwingThread):
3291         (JSC::VM::clearException):
3292
3293 2017-05-13  David Kilzer  <ddkilzer@apple.com>
3294
3295         Unused lambda capture in JSContextGroupAddMarkingConstraint()
3296         <https://webkit.org/b/172084>
3297
3298         Reviewed by Saam Barati.
3299
3300         Fixes the following warning with newer clang:
3301
3302             Source/JavaScriptCore/API/JSMarkingConstraintPrivate.cpp:78:11: error: lambda capture 'vm' is not used [-Werror,-Wunused-lambda-capture]
3303                     [&vm, constraintCallback, userData]
3304                       ^
3305
3306         * API/JSMarkingConstraintPrivate.cpp:
3307         (JSContextGroupAddMarkingConstraint): Remove unused lambda
3308         capture for '&vm'.
3309
3310 2017-05-13  David Kilzer  <ddkilzer@apple.com>
3311
3312         [JSC] config.rb fails when checking some clang versions
3313         <https://webkit.org/b/172082>
3314
3315         Reviewed by Mark Lam.
3316
3317         * offlineasm/config.rb:
3318         - Add support for quad-dotted version of Apple clang (800.0.12.1).
3319         - Add support for checking open source clang version (5.0.0).
3320
3321 2017-05-13  Commit Queue  <commit-queue@webkit.org>
3322
3323         Unreviewed, rolling out r216808.
3324         https://bugs.webkit.org/show_bug.cgi?id=172075
3325
3326         caused lldb to hang when debugging (Requested by smfr on
3327         #webkit).
3328
3329         Reverted changeset:
3330
3331         "Use Mach exceptions instead of signals where possible"
3332         https://bugs.webkit.org/show_bug.cgi?id=171865
3333         http://trac.webkit.org/changeset/216808
3334
3335 2017-05-13  Commit Queue  <commit-queue@webkit.org>
3336
3337         Unreviewed, rolling out r216801.
3338         https://bugs.webkit.org/show_bug.cgi?id=172072
3339
3340         Many memory corruption crashes on worker threads (Requested by
3341         ap on #webkit).
3342
3343         Reverted changeset:
3344
3345         "WorkerRunLoop::Task::performTask() should check
3346         !scriptController->isTerminatingExecution()."
3347         https://bugs.webkit.org/show_bug.cgi?id=171775
3348         http://trac.webkit.org/changeset/216801
3349
3350 2017-05-12  Geoffrey Garen  <ggaren@apple.com>
3351
3352         [JSC] DFG::Node should not have its own allocator
3353         https://bugs.webkit.org/show_bug.cgi?id=160098
3354
3355         Reviewed by Saam Barati.
3356
3357         I just rebased the patch from <http://trac.webkit.org/changeset/203808>.
3358
3359         I ran Octane and JetStream locally on a MacBook Air and I wasn't able to
3360         reproduce a regression. Let's land this again and see what the bots say.
3361
3362         * JavaScriptCore.xcodeproj/project.pbxproj:
3363         * b3/B3SparseCollection.h:
3364         (JSC::B3::SparseCollection::packIndices):
3365         * dfg/DFGAllocator.h: Removed.
3366         * dfg/DFGDriver.cpp:
3367         (JSC::DFG::compileImpl):
3368         * dfg/DFGGraph.cpp:
3369         (JSC::DFG::Graph::Graph):
3370         (JSC::DFG::Graph::~Graph):
3371         (JSC::DFG::Graph::deleteNode):
3372         (JSC::DFG::Graph::packNodeIndices):
3373         (JSC::DFG::Graph::addNodeToMapByIndex): Deleted.
3374         * dfg/DFGGraph.h:
3375         (JSC::DFG::Graph::addNode):
3376         (JSC::DFG::Graph::maxNodeCount):
3377         (JSC::DFG::Graph::nodeAt):
3378         * dfg/DFGLongLivedState.cpp: Removed.
3379         * dfg/DFGLongLivedState.h: Removed.
3380         * dfg/DFGNode.h:
3381         * dfg/DFGNodeAllocator.h:
3382         * dfg/DFGPlan.cpp:
3383         (JSC::DFG::Plan::compileInThread):
3384         (JSC::DFG::Plan::compileInThreadImpl):
3385         * dfg/DFGPlan.h:
3386         * dfg/DFGWorklist.cpp:
3387         * runtime/VM.cpp:
3388         (JSC::VM::VM):
3389         * runtime/VM.h:
3390
3391 2017-05-12  Keith Miller  <keith_miller@apple.com>
3392
3393         Use Mach exceptions instead of signals where possible
3394         https://bugs.webkit.org/show_bug.cgi?id=171865
3395
3396         Reviewed by Mark Lam.
3397
3398         This patch adds some new JSC options. The first is an option that
3399         enables or disables web assembly tier up. The second controls
3400         whether or not we use mach exceptions (where available).
3401
3402         * API/tests/ExecutionTimeLimitTest.cpp:
3403         (dispatchTermitateCallback):
3404         (testExecutionTimeLimit):
3405         * runtime/JSLock.cpp:
3406         (JSC::JSLock::didAcquireLock):
3407         * runtime/Options.cpp:
3408         (JSC::overrideDefaults):
3409         (JSC::Options::initialize):
3410         * runtime/Options.h:
3411         * runtime/VMTraps.cpp:
3412         (JSC::SignalContext::SignalContext):
3413         (JSC::SignalContext::adjustPCToPointToTrappingInstruction):
3414         (JSC::installSignalHandler):
3415         (JSC::VMTraps::SignalSender::send):
3416         * tools/SigillCrashAnalyzer.cpp:
3417         (JSC::SignalContext::SignalContext):
3418         (JSC::SignalContext::dump):
3419         (JSC::installCrashHandler):
3420         * wasm/WasmBBQPlan.cpp:
3421         (JSC::Wasm::BBQPlan::compileFunctions):
3422         * wasm/WasmFaultSignalHandler.cpp:
3423         (JSC::Wasm::trapHandler):
3424         (JSC::Wasm::enableFastMemory):
3425         * wasm/WasmMachineThreads.cpp:
3426         (JSC::Wasm::resetInstructionCacheOnAllThreads):
3427
3428 2017-05-12  Mark Lam  <mark.lam@apple.com>
3429
3430         WorkerRunLoop::Task::performTask() should check !scriptController->isTerminatingExecution().
3431         https://bugs.webkit.org/show_bug.cgi?id=171775
3432         <rdar://problem/30975761>
3433
3434         Reviewed by Saam Barati.
3435
3436         Increased the number of frames captured in VM::nativeStackTraceOfLastThrow()
3437         from 25 to 100.  From experience, I found that 25 is sometimes not sufficient
3438         for our debugging needs.
3439
3440         Also added VM::throwingThread() to track which thread an exception was thrown in.
3441         This may be useful if the client is entering the VM from different threads.
3442
3443         * runtime/ExceptionScope.cpp:
3444         (JSC::ExceptionScope::unexpectedExceptionMessage):
3445         * runtime/ExceptionScope.h:
3446         (JSC::ExceptionScope::exception):
3447         (JSC::ExceptionScope::unexpectedExceptionMessage):
3448         * runtime/Options.h:
3449         - Added the unexpectedExceptionStackTraceLimit option.
3450         * runtime/VM.cpp:
3451         (JSC::VM::throwException):
3452         * runtime/VM.h:
3453         (JSC::VM::throwingThread):
3454         (JSC::VM::clearException):
3455
3456 2017-05-12  Daniel Bates  <dabates@apple.com>
3457
3458         Cleanup: Make QueueTaskToEventLoopFunctionPtr take JSGlobalObject&
3459         https://bugs.webkit.org/show_bug.cgi?id=172021
3460
3461         Reviewed by Mark Lam.
3462
3463         Change the function alias for QueueTaskToEventLoopFunctionPtr to take JSGlobalObject&
3464         instead of a const JSGlobalObject* as all implementations expect to be passed a non-
3465         const, non-null JSGlobalObject object.
3466
3467         * runtime/JSGlobalObject.cpp:
3468         (JSC::JSGlobalObject::queueMicrotask):
3469         * runtime/JSGlobalObject.h:
3470         * runtime/VM.cpp:
3471         (JSC::VM::queueMicrotask):
3472         * runtime/VM.h: Remove JS_EXPORT_PRIVATE annotation from queueMicrotask() as
3473         it is only called from JavaScriptCore code.
3474
3475 2017-05-12  Michael Saboff  <msaboff@apple.com>
3476
3477         [iOS] Use memory footprint to dynamically adjust behavior of allocators
3478         https://bugs.webkit.org/show_bug.cgi?id=171944
3479
3480         Reviewed by Filip Pizlo.
3481
3482         This change is iOS only.
3483
3484         Added the ability to react to when memory usage is critical.  This is defined as memory
3485         usage being above the newly added option criticalGCMemoryThreshold.  When we are in this
3486         critical state, all collections are Full and we limit the amount of memory we allocate
3487         between collections to 1/4th the memory above the critical threshold.
3488
3489         Changed the calculation of proportionalHeapSize to be based on process memory footprint
3490         and not how big the heap is.  Also, the values of Options::smallHeapRAMFraction and
3491         Options::mediumHeapRAMFraction are overriden so that most of the heap growth is happens
3492         using the more agressive Options::smallHeapGrowthFactor.
3493
3494         * heap/Heap.cpp:
3495         (JSC::Heap::Heap):
3496         (JSC::Heap::overCriticalMemoryThreshold):
3497         (JSC::Heap::shouldDoFullCollection):
3498         (JSC::Heap::collectIfNecessaryOrDefer):
3499         * heap/Heap.h:
3500         * runtime/Options.cpp:
3501         (JSC::overrideDefaults):
3502         (JSC::Options::initialize):
3503         * runtime/Options.h:
3504
3505 2017-05-11  Saam Barati  <sbarati@apple.com>
3506
3507         Computing optionalDefArgWidth in CheckSpecial should not consider Scratch roles
3508         https://bugs.webkit.org/show_bug.cgi?id=171962
3509
3510         Reviewed by Filip Pizlo.
3511
3512         The purpose of getting the result width is to get the width of
3513         the result of the arithmetic. It does not care about that the
3514         Check happens to define scratches.
3515
3516         * b3/B3CheckSpecial.cpp:
3517         (JSC::B3::CheckSpecial::forEachArg):
3518         * b3/testb3.cpp:
3519         (JSC::B3::testCheckMul):
3520         (JSC::B3::testCheckMulMemory):
3521         (JSC::B3::testCheckMul64):
3522         (JSC::B3::testCheckMulFold):
3523         (JSC::B3::testCheckMulFoldFail):
3524         (JSC::B3::testCheckMulArgumentAliasing64):
3525         (JSC::B3::testCheckMulArgumentAliasing32):
3526         (JSC::B3::testCheckMul64SShr):
3527
3528 2017-05-11  Saam Barati  <sbarati@apple.com>
3529
3530         isValidForm for SimpleAddr should use ptr() instead of tmp()
3531         https://bugs.webkit.org/show_bug.cgi?id=171992
3532
3533         Reviewed by Filip Pizlo.
3534
3535         Arg::tmp() asserts that its kind is Tmp. Inst::isValidForm for
3536         SimpleAddr was using Arg::tmp() instead of ptr() to check
3537         if the address Tmp isGP(). It should be using Arg::ptr() instead
3538         of Arg::tmp() since Arg::ptr() is designed for SimpleAddr.
3539         
3540         This patch also fixes an incorrect assertion in the ARM64
3541         macro assembler. We were asserting various atomic ops were
3542         only over 32/64 bit operations. However, the code was properly handling
3543         8/16/32/64 bit ops. I changed the assertion to reflect what is
3544         actually going on.
3545
3546         * assembler/ARM64Assembler.h:
3547         (JSC::ARM64Assembler::ldar):
3548         (JSC::ARM64Assembler::ldxr):
3549         (JSC::ARM64Assembler::ldaxr):
3550         (JSC::ARM64Assembler::stxr):
3551         (JSC::ARM64Assembler::stlr):
3552         (JSC::ARM64Assembler::stlxr):
3553         * b3/air/opcode_generator.rb:
3554         * b3/testb3.cpp:
3555         (JSC::B3::testLoadAcq42):
3556         (JSC::B3::testStoreRelAddLoadAcq32):
3557         (JSC::B3::testStoreRelAddLoadAcq8):
3558         (JSC::B3::testStoreRelAddFenceLoadAcq8):
3559         (JSC::B3::testStoreRelAddLoadAcq16):
3560         (JSC::B3::testStoreRelAddLoadAcq64):
3561         (JSC::B3::testAtomicWeakCAS):
3562         (JSC::B3::testAtomicStrongCAS):
3563         (JSC::B3::testAtomicXchg):
3564
3565 2017-05-11  Matt Lewis  <jlewis3@apple.com>
3566
3567         Unreviewed, rolling out r216677.
3568
3569         Patch caused layout test crashes.
3570
3571         Reverted changeset:
3572
3573         "WorkerThread::stop() should call
3574         scheduleExecutionTermination() last."
3575         https://bugs.webkit.org/show_bug.cgi?id=171775
3576         http://trac.webkit.org/changeset/216677
3577
3578 2017-05-11  Don Olmstead  <don.olmstead@am.sony.com>
3579
3580         [CMake] Add HAVE check for regex.h
3581         https://bugs.webkit.org/show_bug.cgi?id=171950
3582
3583         Reviewed by Michael Catanzaro.
3584
3585         * runtime/ConfigFile.cpp:
3586         (JSC::ConfigFile::parse):
3587
3588 2017-05-11  Filip Pizlo  <fpizlo@apple.com>
3589
3590         Callers of JSString::unsafeView() should check exceptions
3591         https://bugs.webkit.org/show_bug.cgi?id=171995
3592
3593         Reviewed by Mark Lam.
3594         
3595         unsafeView() can throw OOME. So, callers of unsafeView() should check for exceptions before trying
3596         to access the view.
3597
3598         Also, I made the functions surrounding unsafeView() take ExecState* not ExecState&, to comply with
3599         the rest of JSC.
3600
3601         * dfg/DFGOperations.cpp:
3602         * jsc.cpp:
3603         (printInternal):
3604         (functionDebug):
3605         * runtime/ArrayPrototype.cpp:
3606         (JSC::arrayProtoFuncJoin):
3607         * runtime/FunctionConstructor.cpp:
3608         (JSC::constructFunctionSkippingEvalEnabledCheck):
3609         * runtime/IntlCollatorPrototype.cpp:
3610         (JSC::IntlCollatorFuncCompare):
3611         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
3612         (JSC::genericTypedArrayViewProtoFuncJoin):
3613         * runtime/JSGlobalObjectFunctions.cpp:
3614         (JSC::globalFuncParseFloat):
3615         * runtime/JSONObject.cpp:
3616         (JSC::JSONProtoFuncParse):
3617         * runtime/JSString.cpp:
3618         (JSC::JSString::getPrimitiveNumber):
3619         (JSC::JSString::toNumber):
3620         * runtime/JSString.h:
3621         (JSC::JSString::getIndex):
3622         (JSC::JSRopeString::unsafeView):
3623         (JSC::JSRopeString::viewWithUnderlyingString):
3624         (JSC::JSString::unsafeView):
3625         (JSC::JSString::viewWithUnderlyingString):
3626         * runtime/JSStringJoiner.h:
3627         (JSC::JSStringJoiner::appendWithoutSideEffects):
3628         (JSC::JSStringJoiner::append):
3629         * runtime/ParseInt.h:
3630         (JSC::toStringView):
3631         * runtime/StringPrototype.cpp:
3632         (JSC::stringProtoFuncRepeatCharacter):
3633         (JSC::stringProtoFuncCharAt):
3634         (JSC::stringProtoFuncCharCodeAt):
3635         (JSC::stringProtoFuncIndexOf):
3636         (JSC::stringProtoFuncNormalize):
3637
3638 2017-05-11  Filip Pizlo  <fpizlo@apple.com>
3639
3640         Offer SPI to notify clients that GC has happened
3641         https://bugs.webkit.org/show_bug.cgi?id=171980
3642
3643         Reviewed by Geoffrey Garen.
3644         
3645         Sometimes when you're programming with weak references, it's most convenient if the GC tells
3646         you when it finishes. This adds exactly such an API. This API is called at the *flip*: the
3647         moment when the GC knows for sure which objects are dead and has definitely not allocated any
3648         new objects or executed any JS code. The finalization part of the flip, which is where this
3649         callback gets called, runs on the "main" thread - i.e. some thread that is attempting to
3650         execute JS code and holds the JS lock. This will usually run as a side-effect of some
3651         allocation or from the runloop.
3652         
3653         This means, for example, that if you implemented a vector of weak references and registered a
3654         callback to prune the vector of null weak references, then aside from the callback, nobody
3655         would ever see a null weak reference in the vector.
3656
3657         * API/JSHeapFinalizerPrivate.cpp: Added.
3658         (JSContextGroupAddHeapFinalizer):
3659         (JSContextGroupRemoveHeapFinalizer):
3660         * API/JSHeapFinalizerPrivate.h: Added.
3661         * API/tests/testapi.c:
3662         (heapFinalizer):
3663         (testMarkingConstraintsAndHeapFinalizers):
3664         (main):
3665         (testMarkingConstraints): Deleted.
3666         * CMakeLists.txt:
3667         * JavaScriptCore.xcodeproj/project.pbxproj:
3668         * heap/Heap.cpp:
3669         (JSC::Heap::finalize):
3670         (JSC::Heap::addHeapFinalizerCallback):
3671         (JSC::Heap::removeHeapFinalizerCallback):
3672         * heap/Heap.h:
3673         * heap/HeapFinalizerCallback.cpp: Added.
3674         (JSC::HeapFinalizerCallback::dump):
3675         * heap/HeapFinalizerCallback.h: Added.
3676         (JSC::HeapFinalizerCallback::HeapFinalizerCallback):
3677         (JSC::HeapFinalizerCallback::operator==):
3678         (JSC::HeapFinalizerCallback::operator!=):
3679         (JSC::HeapFinalizerCallback::operator bool):
3680         (JSC::HeapFinalizerCallback::run):
3681
3682 2017-05-11  Filip Pizlo  <fpizlo@apple.com>
3683
3684         JSWeakCreate/Retain/Release should take a JSContextGroupRef and not a JSContextRef
3685         https://bugs.webkit.org/show_bug.cgi?id=171979
3686
3687         Reviewed by Mark Lam.
3688         
3689         Functions that don't execute arbitrary JS but just need access to the VM should take a
3690         JSContextGroupRef, not a JSContextRef.
3691
3692         * API/JSWeakPrivate.cpp:
3693         (JSWeakCreate):
3694         (JSWeakRetain):
3695         (JSWeakRelease):
3696         * API/JSWeakPrivate.h:
3697         * API/tests/testapi.c:
3698         (testMarkingConstraints):
3699
3700 2017-05-11  Mark Lam  <mark.lam@apple.com>
3701
3702         WorkerThread::stop() should call scheduleExecutionTermination() last.
3703         https://bugs.webkit.org/show_bug.cgi?id=171775
3704         <rdar://problem/30975761>
3705
3706         Reviewed by Geoffrey Garen.
3707
3708         Increased the number of frames captured in VM::nativeStackTraceOfLastThrow()
3709         from 25 to 100.  From experience, I found that 25 is sometimes not sufficient
3710         for our debugging needs.
3711
3712         Also added VM::throwingThread() to track which thread an exception was thrown in.
3713         This may be useful if the client is entering the VM from different threads.
3714
3715         * runtime/ExceptionScope.cpp:
3716         (JSC::ExceptionScope::unexpectedExceptionMessage):
3717         (JSC::ExceptionScope::releaseAssertIsTerminatedExecutionException):
3718         * runtime/ExceptionScope.h:
3719         (JSC::ExceptionScope::exception):
3720         (JSC::ExceptionScope::unexpectedExceptionMessage):
3721         * runtime/VM.cpp:
3722         (JSC::VM::throwException):
3723         * runtime/VM.h:
3724         (JSC::VM::throwingThread):
3725         (JSC::VM::clearException):
3726
3727 2017-05-11  JF Bastien  <jfbastien@apple.com>
3728
3729         WebAssembly: stop supporting 0xD
3730         https://bugs.webkit.org/show_bug.cgi?id=168788
3731         <rdar://problem/31880922>
3732
3733         Reviewed by Saam Barati.
3734
3735         Only version 1 is supported by other browsers, and there shouldn't
3736         be any 0xD binaries in the wild anymore.
3737
3738         * wasm/WasmModuleParser.cpp:
3739
3740 2017-05-09  Sam Weinig  <sam@webkit.org>
3741
3742         Remove support for legacy Notifications
3743         https://bugs.webkit.org/show_bug.cgi?id=171487
3744
3745         Reviewed by Jon Lee.
3746
3747         * Configurations/FeatureDefines.xcconfig:
3748         Remove definition of ENABLE_LEGACY_NOTIFICATIONS.
3749
3750 2017-05-10  Commit Queue  <commit-queue@webkit.org>
3751
3752         Unreviewed, rolling out r216635.
3753         https://bugs.webkit.org/show_bug.cgi?id=171953
3754
3755         "Some worker tests are failing". (Requested by mlam on #webkit).
3756
3757         Reverted changeset:
3758
3759         "WorkerThread::stop() should call
3760         scheduleExecutionTermination() last."
3761         https://bugs.webkit.org/show_bug.cgi?id=171775
3762         http://trac.webkit.org/changeset/216635
3763
3764 2017-05-10  Mark Lam  <mark.lam@apple.com>
3765
3766         Crash in JavaScriptCore GC when using JSC on dispatch queues (thread_get_state returns NULL stack pointer).
3767         https://bugs.webkit.org/show_bug.cgi?id=160337
3768         <rdar://problem/27611733>
3769
3770         Not reviewed.
3771
3772         Updated a comment per Geoff's suggestion.
3773
3774         * heap/MachineStackMarker.cpp:
3775         (JSC::MachineThreads::tryCopyOtherThreadStack):
3776
3777 2017-05-10  Mark Lam  <mark.lam@apple.com>
3778
3779         WorkerThread::stop() should call scheduleExecutionTermination() last.
3780         https://bugs.webkit.org/show_bug.cgi?id=171775
3781         <rdar://problem/30975761>
3782
3783         Reviewed by Geoffrey Garen.
3784
3785         Increased the number of frames captured in VM::nativeStackTraceOfLastThrow()
3786         from 25 to 100.  From experience, I found that 25 is sometimes not sufficient
3787         for our debugging needs.
3788
3789         Also added VM::throwingThread() to track which thread an exception was thrown in.
3790         This may be useful if the client is entering the VM from different threads.
3791
3792         * runtime/ExceptionScope.cpp:
3793         (JSC::ExceptionScope::unexpectedExceptionMessage):
3794         (JSC::ExceptionScope::releaseAssertIsTerminatedExecutionException):
3795         * runtime/ExceptionScope.h:
3796         (JSC::ExceptionScope::exception):
3797         (JSC::ExceptionScope::unexpectedExceptionMessage):
3798         * runtime/VM.cpp:
3799         (JSC::VM::throwException):
3800         * runtime/VM.h:
3801         (JSC::VM::throwingThread):
3802         (JSC::VM::clearException):
3803
3804 2017-05-10  Mark Lam  <mark.lam@apple.com>
3805
3806         Crash in JavaScriptCore GC when using JSC on dispatch queues (thread_get_state returns NULL stack pointer).
3807         https://bugs.webkit.org/show_bug.cgi?id=160337
3808         <rdar://problem/27611733>
3809
3810         Reviewed by Filip Pizlo and Geoffrey Garen.
3811
3812         This is a workaround for <rdar://problem/27607384>. During thread initialization,
3813         for some target platforms, thread state is momentarily set to 0 before being
3814         filled in with the target thread's real register values. As a result, there's
3815         a race condition that may result in us getting a null stackPointer during a GC scan.
3816         This issue may manifest with workqueue threads where the OS may choose to recycle
3817         a thread for an expired task.
3818
3819         The workaround is simply to indicate that there's nothing to copy and return.
3820         This is correct because we will only ever observe a null pointer during thread
3821         initialization. Hence, by definition, there's nothing there that we need to scan
3822         yet, and therefore, nothing that needs to be copied.
3823
3824         * heap/MachineStackMarker.cpp:
3825         (JSC::MachineThreads::tryCopyOtherThreadStack):
3826
3827 2017-05-10  JF Bastien  <jfbastien@apple.com>
3828
3829         WebAssembly: support name section
3830
3831         https://bugs.webkit.org/show_bug.cgi?id=171263
3832
3833         Reviewed by Keith Miller.
3834
3835         The name section is an optional custom section in the WebAssembly
3836         spec. At least when debugging, developers expect to be able to use
3837         this section to obtain intelligible stack traces, otherwise we
3838         just number the wasm functions which is somewhat painful.
3839
3840         This patch parses this section, dropping its content eagerly on
3841         error, and if there is a name section then backtraces use their
3842         value instead of numbers. Otherwise we stick to numbers as before.
3843
3844         Note that the format of name sections changed in mid-February:
3845           https://github.com/WebAssembly/design/pull/984
3846         And binaryen was only updated in early March:
3847           https://github.com/WebAssembly/binaryen/pull/933
3848
3849         * CMakeLists.txt:
3850         * JavaScriptCore.xcodeproj/project.pbxproj:
3851         * interpreter/Interpreter.cpp:
3852         (JSC::GetStackTraceFunctor::operator()):
3853         * interpreter/StackVisitor.cpp:
3854         (JSC::StackVisitor::readNonInlinedFrame):
3855         (JSC::StackVisitor::Frame::functionName):
3856         * interpreter/StackVisitor.h:
3857         (JSC::StackVisitor::Frame::wasmFunctionIndexOrName):
3858         * runtime/StackFrame.cpp:
3859         (JSC::StackFrame::functionName):
3860         * runtime/StackFrame.h:
3861         (JSC::StackFrame::StackFrame):
3862         (JSC::StackFrame::wasm):
3863         * wasm/WasmBBQPlanInlines.h:
3864         (JSC::Wasm::BBQPlan::initializeCallees):
3865         * wasm/WasmCallee.cpp:
3866         (JSC::Wasm::Callee::Callee):
3867         * wasm/WasmCallee.h:
3868         (JSC::Wasm::Callee::create):
3869         (JSC::Wasm::Callee::indexOrName):
3870         * wasm/WasmFormat.cpp:
3871         (JSC::Wasm::makeString):
3872         * wasm/WasmFormat.h:
3873         (JSC::Wasm::isValidExternalKind):
3874         (JSC::Wasm::isValidNameType):
3875         (JSC::Wasm::NameSection::get):
3876         * wasm/WasmIndexOrName.cpp: Copied from Source/JavaScriptCore/wasm/WasmCallee.cpp.
3877         (JSC::Wasm::IndexOrName::IndexOrName):
3878         (JSC::Wasm::makeString):
3879         * wasm/WasmIndexOrName.h: Copied from Source/JavaScriptCore/wasm/WasmFormat.cpp.
3880         * wasm/WasmModuleInformation.h:
3881         * wasm/WasmModuleParser.cpp:
3882         * wasm/WasmName.h: Copied from Source/JavaScriptCore/wasm/WasmCallee.cpp.
3883         * wasm/WasmNameSectionParser.cpp: Added.
3884         * wasm/WasmNameSectionParser.h: Copied from Source/JavaScriptCore/wasm/WasmCallee.cpp.
3885         (JSC::Wasm::NameSectionParser::NameSectionParser):
3886         * wasm/WasmOMGPlan.cpp:
3887         (JSC::Wasm::OMGPlan::work):
3888         * wasm/WasmParser.h:
3889         (JSC::Wasm::Parser<SuccessType>::consumeUTF8String):
3890
3891 2017-05-10  Filip Pizlo  <fpizlo@apple.com>
3892
3893         Null pointer dereference in WTF::RefPtr<WTF::StringImpl>::operator!() under slow_path_get_direct_pname
3894         https://bugs.webkit.org/show_bug.cgi?id=171801
3895
3896         Reviewed by Michael Saboff.
3897         
3898         This was a goofy oversight. The for-in optimization relies on the bytecode generator
3899         to detect when the loop's index variable gets mutated. We forgot to have the hooks for
3900         detecting this in prefix and postfix operations (++i and i++).
3901
3902         * bytecompiler/NodesCodegen.cpp:
3903         (JSC::PostfixNode::emitResolve):
3904         (JSC::PrefixNode::emitResolve):
3905
3906 2017-05-10  Michael Catanzaro  <mcatanzaro@igalia.com>
3907
3908         [GTK] -Wmissing-field-initializers triggered by RemoteInspectorServer.cpp:128
3909         https://bugs.webkit.org/show_bug.cgi?id=171273
3910
3911         Reviewed by Carlos Garcia Campos.
3912
3913         * inspector/remote/glib/RemoteInspectorGlib.cpp:
3914         * inspector/remote/glib/RemoteInspectorServer.cpp:
3915
3916 2017-05-10  Adrian Perez de Castro  <aperez@igalia.com>
3917
3918         Remove some last remnants of the EFL port
3919         https://bugs.webkit.org/show_bug.cgi?id=171922
3920
3921         Reviewed by Antonio Gomes.
3922
3923         The EFL port is no more.
3924
3925         * PlatformEfl.cmake: Removed.
3926         * shell/PlatformEfl.cmake: Removed.
3927
3928 2017-05-09  Filip Pizlo  <fpizlo@apple.com>
3929
3930         JSInjectedScriptHost should get a copy of the boundArgs
3931         https://bugs.webkit.org/show_bug.cgi?id=171897
3932
3933         Reviewed by Joseph Pecoraro.
3934         
3935         The boundArgs array is very special - it cannot be mutated in any way. So, it makes sense
3936         for the inspector to get a copy of it.
3937
3938         * inspector/JSInjectedScriptHost.cpp:
3939         (Inspector::JSInjectedScriptHost::getInternalProperties):
3940         * runtime/JSBoundFunction.cpp:
3941         (JSC::JSBoundFunction::boundArgsCopy):
3942         * runtime/JSBoundFunction.h:
3943         (JSC::JSBoundFunction::boundArgs):
3944
3945 2017-05-09  Mark Lam  <mark.lam@apple.com>
3946
3947         Unindent some code in Watchdog::shouldTerminate().
3948         https://bugs.webkit.org/show_bug.cgi?id=171896
3949
3950         Rubber stamped by Keith Miller.
3951
3952         I should have done this before I landed r213107, but I forgot.  Unindenting it now.
3953
3954         * runtime/Watchdog.cpp:
3955         (JSC::Watchdog::shouldTerminate):
3956
3957 2017-05-09  Michael Saboff  <msaboff@apple.com>
3958
3959         Cap the number of FTL compilation threads on iOS to 2
3960         https://bugs.webkit.org/show_bug.cgi?id=171887
3961
3962         Reviewed by Filip Pizlo.
3963
3964         Set an iOS specific max of 2 threads.
3965
3966         * runtime/Options.h:
3967
3968 2017-05-09  Filip Pizlo  <fpizlo@apple.com>
3969
3970         Heap::heap() should behave gracefully for null pointers
3971         https://bugs.webkit.org/show_bug.cgi?id=171888
3972         <rdar://problem/32005315>
3973
3974         Reviewed by Mark Lam.
3975         
3976         Some callers of Heap::heap() can pass a null cell and they will behave gracefully if we
3977         return a null Heap. So, let's do that.
3978         
3979         This fixes a crash and it does not hurt performance. I'm seeing a possible 0.5% regression
3980         with 74% probability. That's a neutral result by our usual 95% standard.
3981
3982         * heap/HeapInlines.h:
3983         (JSC::Heap::heap):
3984
3985 2017-05-09  Yusuke Suzuki  <utatane.tea@gmail.com>
3986
3987         Handle IDLPromise<> properly
3988         https://bugs.webkit.org/show_bug.cgi?id=166752
3989
3990         Reviewed by Youenn Fablet.
3991
3992         Add JSPromise::resolve static function.
3993         This applies `Promise.resolve()` conversion to a given value.
3994
3995         * runtime/JSGlobalObject.cpp:
3996         (JSC::JSGlobalObject::init):
3997         (JSC::JSGlobalObject::visitChildren):
3998         * runtime/JSGlobalObject.h:
3999         (JSC::JSGlobalObject::promiseResolveFunction):
4000         * runtime/JSPromise.cpp:
4001         (JSC::JSPromise::resolve):
4002         * runtime/JSPromise.h:
4003
4004 2017-05-09  Zan Dobersek  <zdobersek@igalia.com>
4005
4006         Upstream the WPE port
4007         https://bugs.webkit.org/show_bug.cgi?id=171110
4008
4009         Reviewed by Alex Christensen.
4010
4011         * PlatformWPE.cmake: Added.
4012         * shell/PlatformWPE.cmake: Added.
4013
4014 2017-05-09  Saam Barati  <sbarati@apple.com>
4015
4016         CallLinkInfos belonging to Wasm->JS stubs need to be informed when we clearCode() from all Executables
4017         https://bugs.webkit.org/show_bug.cgi?id=171707
4018         <rdar://problem/31891649>
4019
4020         Reviewed by Filip Pizlo.
4021
4022         This patch fixes a bug where a Wasm->JS IC call stub would go stale
4023         and point into a CodeBlock no longer owned by any executable. The
4024         problematic scenario is this:
4025
4026         1. We generate the call IC which has a branch on a callee check. This