a2da9dfa7e733314824837c8e173f5bb0c673c6b
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2017-05-15  David Kilzer  <ddkilzer@apple.com>
2
3         JSEnvironmentRecord::allocationSizeForScopeSize() and offsetOfVariable(ScopeOffset) should used checked arithmetic
4         <https://webkit.org/b/172134>
5
6         Reviewed by Saam Barati.
7
8         * runtime/JSEnvironmentRecord.h:
9         (JSC::JSEnvironmentRecord::offsetOfVariable): Change to return
10         size_t and use checked arithmetic.
11         (JSC::JSEnvironmentRecord::allocationSizeForScopeSize): Change
12         to use checked arithmetic.
13
14 2017-05-15  Mark Lam  <mark.lam@apple.com>
15
16         WorkerRunLoop::Task::performTask() should check !scriptController->isTerminatingExecution().
17         https://bugs.webkit.org/show_bug.cgi?id=171775
18         <rdar://problem/30975761>
19
20         Reviewed by Filip Pizlo.
21
22         Increased the number of frames captured in VM::nativeStackTraceOfLastThrow()
23         from 25 to 100.  From experience, I found that 25 is sometimes not sufficient
24         for our debugging needs.
25
26         Also added VM::throwingThread() to track which thread an exception was thrown in.
27         This may be useful if the client is entering the VM from different threads.
28
29         * runtime/ExceptionScope.cpp:
30         (JSC::ExceptionScope::unexpectedExceptionMessage):
31         * runtime/ExceptionScope.h:
32         (JSC::ExceptionScope::exception):
33         (JSC::ExceptionScope::unexpectedExceptionMessage):
34         * runtime/Options.h:
35         - Added the unexpectedExceptionStackTraceLimit option.
36         * runtime/VM.cpp:
37         (JSC::VM::throwException):
38         * runtime/VM.h:
39         (JSC::VM::throwingThread):
40         (JSC::VM::clearException):
41
42 2017-05-13  David Kilzer  <ddkilzer@apple.com>
43
44         Unused lambda capture in JSContextGroupAddMarkingConstraint()
45         <https://webkit.org/b/172084>
46
47         Reviewed by Saam Barati.
48
49         Fixes the following warning with newer clang:
50
51             Source/JavaScriptCore/API/JSMarkingConstraintPrivate.cpp:78:11: error: lambda capture 'vm' is not used [-Werror,-Wunused-lambda-capture]
52                     [&vm, constraintCallback, userData]
53                       ^
54
55         * API/JSMarkingConstraintPrivate.cpp:
56         (JSContextGroupAddMarkingConstraint): Remove unused lambda
57         capture for '&vm'.
58
59 2017-05-13  David Kilzer  <ddkilzer@apple.com>
60
61         [JSC] config.rb fails when checking some clang versions
62         <https://webkit.org/b/172082>
63
64         Reviewed by Mark Lam.
65
66         * offlineasm/config.rb:
67         - Add support for quad-dotted version of Apple clang (800.0.12.1).
68         - Add support for checking open source clang version (5.0.0).
69
70 2017-05-13  Commit Queue  <commit-queue@webkit.org>
71
72         Unreviewed, rolling out r216808.
73         https://bugs.webkit.org/show_bug.cgi?id=172075
74
75         caused lldb to hang when debugging (Requested by smfr on
76         #webkit).
77
78         Reverted changeset:
79
80         "Use Mach exceptions instead of signals where possible"
81         https://bugs.webkit.org/show_bug.cgi?id=171865
82         http://trac.webkit.org/changeset/216808
83
84 2017-05-13  Commit Queue  <commit-queue@webkit.org>
85
86         Unreviewed, rolling out r216801.
87         https://bugs.webkit.org/show_bug.cgi?id=172072
88
89         Many memory corruption crashes on worker threads (Requested by
90         ap on #webkit).
91
92         Reverted changeset:
93
94         "WorkerRunLoop::Task::performTask() should check
95         !scriptController->isTerminatingExecution()."
96         https://bugs.webkit.org/show_bug.cgi?id=171775
97         http://trac.webkit.org/changeset/216801
98
99 2017-05-12  Geoffrey Garen  <ggaren@apple.com>
100
101         [JSC] DFG::Node should not have its own allocator
102         https://bugs.webkit.org/show_bug.cgi?id=160098
103
104         Reviewed by Saam Barati.
105
106         I just rebased the patch from <http://trac.webkit.org/changeset/203808>.
107
108         I ran Octane and JetStream locally on a MacBook Air and I wasn't able to
109         reproduce a regression. Let's land this again and see what the bots say.
110
111         * JavaScriptCore.xcodeproj/project.pbxproj:
112         * b3/B3SparseCollection.h:
113         (JSC::B3::SparseCollection::packIndices):
114         * dfg/DFGAllocator.h: Removed.
115         * dfg/DFGDriver.cpp:
116         (JSC::DFG::compileImpl):
117         * dfg/DFGGraph.cpp:
118         (JSC::DFG::Graph::Graph):
119         (JSC::DFG::Graph::~Graph):
120         (JSC::DFG::Graph::deleteNode):
121         (JSC::DFG::Graph::packNodeIndices):
122         (JSC::DFG::Graph::addNodeToMapByIndex): Deleted.
123         * dfg/DFGGraph.h:
124         (JSC::DFG::Graph::addNode):
125         (JSC::DFG::Graph::maxNodeCount):
126         (JSC::DFG::Graph::nodeAt):
127         * dfg/DFGLongLivedState.cpp: Removed.
128         * dfg/DFGLongLivedState.h: Removed.
129         * dfg/DFGNode.h:
130         * dfg/DFGNodeAllocator.h:
131         * dfg/DFGPlan.cpp:
132         (JSC::DFG::Plan::compileInThread):
133         (JSC::DFG::Plan::compileInThreadImpl):
134         * dfg/DFGPlan.h:
135         * dfg/DFGWorklist.cpp:
136         * runtime/VM.cpp:
137         (JSC::VM::VM):
138         * runtime/VM.h:
139
140 2017-05-12  Keith Miller  <keith_miller@apple.com>
141
142         Use Mach exceptions instead of signals where possible
143         https://bugs.webkit.org/show_bug.cgi?id=171865
144
145         Reviewed by Mark Lam.
146
147         This patch adds some new JSC options. The first is an option that
148         enables or disables web assembly tier up. The second controls
149         whether or not we use mach exceptions (where available).
150
151         * API/tests/ExecutionTimeLimitTest.cpp:
152         (dispatchTermitateCallback):
153         (testExecutionTimeLimit):
154         * runtime/JSLock.cpp:
155         (JSC::JSLock::didAcquireLock):
156         * runtime/Options.cpp:
157         (JSC::overrideDefaults):
158         (JSC::Options::initialize):
159         * runtime/Options.h:
160         * runtime/VMTraps.cpp:
161         (JSC::SignalContext::SignalContext):
162         (JSC::SignalContext::adjustPCToPointToTrappingInstruction):
163         (JSC::installSignalHandler):
164         (JSC::VMTraps::SignalSender::send):
165         * tools/SigillCrashAnalyzer.cpp:
166         (JSC::SignalContext::SignalContext):
167         (JSC::SignalContext::dump):
168         (JSC::installCrashHandler):
169         * wasm/WasmBBQPlan.cpp:
170         (JSC::Wasm::BBQPlan::compileFunctions):
171         * wasm/WasmFaultSignalHandler.cpp:
172         (JSC::Wasm::trapHandler):
173         (JSC::Wasm::enableFastMemory):
174         * wasm/WasmMachineThreads.cpp:
175         (JSC::Wasm::resetInstructionCacheOnAllThreads):
176
177 2017-05-12  Mark Lam  <mark.lam@apple.com>
178
179         WorkerRunLoop::Task::performTask() should check !scriptController->isTerminatingExecution().
180         https://bugs.webkit.org/show_bug.cgi?id=171775
181         <rdar://problem/30975761>
182
183         Reviewed by Saam Barati.
184
185         Increased the number of frames captured in VM::nativeStackTraceOfLastThrow()
186         from 25 to 100.  From experience, I found that 25 is sometimes not sufficient
187         for our debugging needs.
188
189         Also added VM::throwingThread() to track which thread an exception was thrown in.
190         This may be useful if the client is entering the VM from different threads.
191
192         * runtime/ExceptionScope.cpp:
193         (JSC::ExceptionScope::unexpectedExceptionMessage):
194         * runtime/ExceptionScope.h:
195         (JSC::ExceptionScope::exception):
196         (JSC::ExceptionScope::unexpectedExceptionMessage):
197         * runtime/Options.h:
198         - Added the unexpectedExceptionStackTraceLimit option.
199         * runtime/VM.cpp:
200         (JSC::VM::throwException):
201         * runtime/VM.h:
202         (JSC::VM::throwingThread):
203         (JSC::VM::clearException):
204
205 2017-05-12  Daniel Bates  <dabates@apple.com>
206
207         Cleanup: Make QueueTaskToEventLoopFunctionPtr take JSGlobalObject&
208         https://bugs.webkit.org/show_bug.cgi?id=172021
209
210         Reviewed by Mark Lam.
211
212         Change the function alias for QueueTaskToEventLoopFunctionPtr to take JSGlobalObject&
213         instead of a const JSGlobalObject* as all implementations expect to be passed a non-
214         const, non-null JSGlobalObject object.
215
216         * runtime/JSGlobalObject.cpp:
217         (JSC::JSGlobalObject::queueMicrotask):
218         * runtime/JSGlobalObject.h:
219         * runtime/VM.cpp:
220         (JSC::VM::queueMicrotask):
221         * runtime/VM.h: Remove JS_EXPORT_PRIVATE annotation from queueMicrotask() as
222         it is only called from JavaScriptCore code.
223
224 2017-05-12  Michael Saboff  <msaboff@apple.com>
225
226         [iOS] Use memory footprint to dynamically adjust behavior of allocators
227         https://bugs.webkit.org/show_bug.cgi?id=171944
228
229         Reviewed by Filip Pizlo.
230
231         This change is iOS only.
232
233         Added the ability to react to when memory usage is critical.  This is defined as memory
234         usage being above the newly added option criticalGCMemoryThreshold.  When we are in this
235         critical state, all collections are Full and we limit the amount of memory we allocate
236         between collections to 1/4th the memory above the critical threshold.
237
238         Changed the calculation of proportionalHeapSize to be based on process memory footprint
239         and not how big the heap is.  Also, the values of Options::smallHeapRAMFraction and
240         Options::mediumHeapRAMFraction are overriden so that most of the heap growth is happens
241         using the more agressive Options::smallHeapGrowthFactor.
242
243         * heap/Heap.cpp:
244         (JSC::Heap::Heap):
245         (JSC::Heap::overCriticalMemoryThreshold):
246         (JSC::Heap::shouldDoFullCollection):
247         (JSC::Heap::collectIfNecessaryOrDefer):
248         * heap/Heap.h:
249         * runtime/Options.cpp:
250         (JSC::overrideDefaults):
251         (JSC::Options::initialize):
252         * runtime/Options.h:
253
254 2017-05-11  Saam Barati  <sbarati@apple.com>
255
256         Computing optionalDefArgWidth in CheckSpecial should not consider Scratch roles
257         https://bugs.webkit.org/show_bug.cgi?id=171962
258
259         Reviewed by Filip Pizlo.
260
261         The purpose of getting the result width is to get the width of
262         the result of the arithmetic. It does not care about that the
263         Check happens to define scratches.
264
265         * b3/B3CheckSpecial.cpp:
266         (JSC::B3::CheckSpecial::forEachArg):
267         * b3/testb3.cpp:
268         (JSC::B3::testCheckMul):
269         (JSC::B3::testCheckMulMemory):
270         (JSC::B3::testCheckMul64):
271         (JSC::B3::testCheckMulFold):
272         (JSC::B3::testCheckMulFoldFail):
273         (JSC::B3::testCheckMulArgumentAliasing64):
274         (JSC::B3::testCheckMulArgumentAliasing32):
275         (JSC::B3::testCheckMul64SShr):
276
277 2017-05-11  Saam Barati  <sbarati@apple.com>
278
279         isValidForm for SimpleAddr should use ptr() instead of tmp()
280         https://bugs.webkit.org/show_bug.cgi?id=171992
281
282         Reviewed by Filip Pizlo.
283
284         Arg::tmp() asserts that its kind is Tmp. Inst::isValidForm for
285         SimpleAddr was using Arg::tmp() instead of ptr() to check
286         if the address Tmp isGP(). It should be using Arg::ptr() instead
287         of Arg::tmp() since Arg::ptr() is designed for SimpleAddr.
288         
289         This patch also fixes an incorrect assertion in the ARM64
290         macro assembler. We were asserting various atomic ops were
291         only over 32/64 bit operations. However, the code was properly handling
292         8/16/32/64 bit ops. I changed the assertion to reflect what is
293         actually going on.
294
295         * assembler/ARM64Assembler.h:
296         (JSC::ARM64Assembler::ldar):
297         (JSC::ARM64Assembler::ldxr):
298         (JSC::ARM64Assembler::ldaxr):
299         (JSC::ARM64Assembler::stxr):
300         (JSC::ARM64Assembler::stlr):
301         (JSC::ARM64Assembler::stlxr):
302         * b3/air/opcode_generator.rb:
303         * b3/testb3.cpp:
304         (JSC::B3::testLoadAcq42):
305         (JSC::B3::testStoreRelAddLoadAcq32):
306         (JSC::B3::testStoreRelAddLoadAcq8):
307         (JSC::B3::testStoreRelAddFenceLoadAcq8):
308         (JSC::B3::testStoreRelAddLoadAcq16):
309         (JSC::B3::testStoreRelAddLoadAcq64):
310         (JSC::B3::testAtomicWeakCAS):
311         (JSC::B3::testAtomicStrongCAS):
312         (JSC::B3::testAtomicXchg):
313
314 2017-05-11  Matt Lewis  <jlewis3@apple.com>
315
316         Unreviewed, rolling out r216677.
317
318         Patch caused layout test crashes.
319
320         Reverted changeset:
321
322         "WorkerThread::stop() should call
323         scheduleExecutionTermination() last."
324         https://bugs.webkit.org/show_bug.cgi?id=171775
325         http://trac.webkit.org/changeset/216677
326
327 2017-05-11  Don Olmstead  <don.olmstead@am.sony.com>
328
329         [CMake] Add HAVE check for regex.h
330         https://bugs.webkit.org/show_bug.cgi?id=171950
331
332         Reviewed by Michael Catanzaro.
333
334         * runtime/ConfigFile.cpp:
335         (JSC::ConfigFile::parse):
336
337 2017-05-11  Filip Pizlo  <fpizlo@apple.com>
338
339         Callers of JSString::unsafeView() should check exceptions
340         https://bugs.webkit.org/show_bug.cgi?id=171995
341
342         Reviewed by Mark Lam.
343         
344         unsafeView() can throw OOME. So, callers of unsafeView() should check for exceptions before trying
345         to access the view.
346
347         Also, I made the functions surrounding unsafeView() take ExecState* not ExecState&, to comply with
348         the rest of JSC.
349
350         * dfg/DFGOperations.cpp:
351         * jsc.cpp:
352         (printInternal):
353         (functionDebug):
354         * runtime/ArrayPrototype.cpp:
355         (JSC::arrayProtoFuncJoin):
356         * runtime/FunctionConstructor.cpp:
357         (JSC::constructFunctionSkippingEvalEnabledCheck):
358         * runtime/IntlCollatorPrototype.cpp:
359         (JSC::IntlCollatorFuncCompare):
360         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
361         (JSC::genericTypedArrayViewProtoFuncJoin):
362         * runtime/JSGlobalObjectFunctions.cpp:
363         (JSC::globalFuncParseFloat):
364         * runtime/JSONObject.cpp:
365         (JSC::JSONProtoFuncParse):
366         * runtime/JSString.cpp:
367         (JSC::JSString::getPrimitiveNumber):
368         (JSC::JSString::toNumber):
369         * runtime/JSString.h:
370         (JSC::JSString::getIndex):
371         (JSC::JSRopeString::unsafeView):
372         (JSC::JSRopeString::viewWithUnderlyingString):
373         (JSC::JSString::unsafeView):
374         (JSC::JSString::viewWithUnderlyingString):
375         * runtime/JSStringJoiner.h:
376         (JSC::JSStringJoiner::appendWithoutSideEffects):
377         (JSC::JSStringJoiner::append):
378         * runtime/ParseInt.h:
379         (JSC::toStringView):
380         * runtime/StringPrototype.cpp:
381         (JSC::stringProtoFuncRepeatCharacter):
382         (JSC::stringProtoFuncCharAt):
383         (JSC::stringProtoFuncCharCodeAt):
384         (JSC::stringProtoFuncIndexOf):
385         (JSC::stringProtoFuncNormalize):
386
387 2017-05-11  Filip Pizlo  <fpizlo@apple.com>
388
389         Offer SPI to notify clients that GC has happened
390         https://bugs.webkit.org/show_bug.cgi?id=171980
391
392         Reviewed by Geoffrey Garen.
393         
394         Sometimes when you're programming with weak references, it's most convenient if the GC tells
395         you when it finishes. This adds exactly such an API. This API is called at the *flip*: the
396         moment when the GC knows for sure which objects are dead and has definitely not allocated any
397         new objects or executed any JS code. The finalization part of the flip, which is where this
398         callback gets called, runs on the "main" thread - i.e. some thread that is attempting to
399         execute JS code and holds the JS lock. This will usually run as a side-effect of some
400         allocation or from the runloop.
401         
402         This means, for example, that if you implemented a vector of weak references and registered a
403         callback to prune the vector of null weak references, then aside from the callback, nobody
404         would ever see a null weak reference in the vector.
405
406         * API/JSHeapFinalizerPrivate.cpp: Added.
407         (JSContextGroupAddHeapFinalizer):
408         (JSContextGroupRemoveHeapFinalizer):
409         * API/JSHeapFinalizerPrivate.h: Added.
410         * API/tests/testapi.c:
411         (heapFinalizer):
412         (testMarkingConstraintsAndHeapFinalizers):
413         (main):
414         (testMarkingConstraints): Deleted.
415         * CMakeLists.txt:
416         * JavaScriptCore.xcodeproj/project.pbxproj:
417         * heap/Heap.cpp:
418         (JSC::Heap::finalize):
419         (JSC::Heap::addHeapFinalizerCallback):
420         (JSC::Heap::removeHeapFinalizerCallback):
421         * heap/Heap.h:
422         * heap/HeapFinalizerCallback.cpp: Added.
423         (JSC::HeapFinalizerCallback::dump):
424         * heap/HeapFinalizerCallback.h: Added.
425         (JSC::HeapFinalizerCallback::HeapFinalizerCallback):
426         (JSC::HeapFinalizerCallback::operator==):
427         (JSC::HeapFinalizerCallback::operator!=):
428         (JSC::HeapFinalizerCallback::operator bool):
429         (JSC::HeapFinalizerCallback::run):
430
431 2017-05-11  Filip Pizlo  <fpizlo@apple.com>
432
433         JSWeakCreate/Retain/Release should take a JSContextGroupRef and not a JSContextRef
434         https://bugs.webkit.org/show_bug.cgi?id=171979
435
436         Reviewed by Mark Lam.
437         
438         Functions that don't execute arbitrary JS but just need access to the VM should take a
439         JSContextGroupRef, not a JSContextRef.
440
441         * API/JSWeakPrivate.cpp:
442         (JSWeakCreate):
443         (JSWeakRetain):
444         (JSWeakRelease):
445         * API/JSWeakPrivate.h:
446         * API/tests/testapi.c:
447         (testMarkingConstraints):
448
449 2017-05-11  Mark Lam  <mark.lam@apple.com>
450
451         WorkerThread::stop() should call scheduleExecutionTermination() last.
452         https://bugs.webkit.org/show_bug.cgi?id=171775
453         <rdar://problem/30975761>
454
455         Reviewed by Geoffrey Garen.
456
457         Increased the number of frames captured in VM::nativeStackTraceOfLastThrow()
458         from 25 to 100.  From experience, I found that 25 is sometimes not sufficient
459         for our debugging needs.
460
461         Also added VM::throwingThread() to track which thread an exception was thrown in.
462         This may be useful if the client is entering the VM from different threads.
463
464         * runtime/ExceptionScope.cpp:
465         (JSC::ExceptionScope::unexpectedExceptionMessage):
466         (JSC::ExceptionScope::releaseAssertIsTerminatedExecutionException):
467         * runtime/ExceptionScope.h:
468         (JSC::ExceptionScope::exception):
469         (JSC::ExceptionScope::unexpectedExceptionMessage):
470         * runtime/VM.cpp:
471         (JSC::VM::throwException):
472         * runtime/VM.h:
473         (JSC::VM::throwingThread):
474         (JSC::VM::clearException):
475
476 2017-05-11  JF Bastien  <jfbastien@apple.com>
477
478         WebAssembly: stop supporting 0xD
479         https://bugs.webkit.org/show_bug.cgi?id=168788
480         <rdar://problem/31880922>
481
482         Reviewed by Saam Barati.
483
484         Only version 1 is supported by other browsers, and there shouldn't
485         be any 0xD binaries in the wild anymore.
486
487         * wasm/WasmModuleParser.cpp:
488
489 2017-05-09  Sam Weinig  <sam@webkit.org>
490
491         Remove support for legacy Notifications
492         https://bugs.webkit.org/show_bug.cgi?id=171487
493
494         Reviewed by Jon Lee.
495
496         * Configurations/FeatureDefines.xcconfig:
497         Remove definition of ENABLE_LEGACY_NOTIFICATIONS.
498
499 2017-05-10  Commit Queue  <commit-queue@webkit.org>
500
501         Unreviewed, rolling out r216635.
502         https://bugs.webkit.org/show_bug.cgi?id=171953
503
504         "Some worker tests are failing". (Requested by mlam on #webkit).
505
506         Reverted changeset:
507
508         "WorkerThread::stop() should call
509         scheduleExecutionTermination() last."
510         https://bugs.webkit.org/show_bug.cgi?id=171775
511         http://trac.webkit.org/changeset/216635
512
513 2017-05-10  Mark Lam  <mark.lam@apple.com>
514
515         Crash in JavaScriptCore GC when using JSC on dispatch queues (thread_get_state returns NULL stack pointer).
516         https://bugs.webkit.org/show_bug.cgi?id=160337
517         <rdar://problem/27611733>
518
519         Not reviewed.
520
521         Updated a comment per Geoff's suggestion.
522
523         * heap/MachineStackMarker.cpp:
524         (JSC::MachineThreads::tryCopyOtherThreadStack):
525
526 2017-05-10  Mark Lam  <mark.lam@apple.com>
527
528         WorkerThread::stop() should call scheduleExecutionTermination() last.
529         https://bugs.webkit.org/show_bug.cgi?id=171775
530         <rdar://problem/30975761>
531
532         Reviewed by Geoffrey Garen.
533
534         Increased the number of frames captured in VM::nativeStackTraceOfLastThrow()
535         from 25 to 100.  From experience, I found that 25 is sometimes not sufficient
536         for our debugging needs.
537
538         Also added VM::throwingThread() to track which thread an exception was thrown in.
539         This may be useful if the client is entering the VM from different threads.
540
541         * runtime/ExceptionScope.cpp:
542         (JSC::ExceptionScope::unexpectedExceptionMessage):
543         (JSC::ExceptionScope::releaseAssertIsTerminatedExecutionException):
544         * runtime/ExceptionScope.h:
545         (JSC::ExceptionScope::exception):
546         (JSC::ExceptionScope::unexpectedExceptionMessage):
547         * runtime/VM.cpp:
548         (JSC::VM::throwException):
549         * runtime/VM.h:
550         (JSC::VM::throwingThread):
551         (JSC::VM::clearException):
552
553 2017-05-10  Mark Lam  <mark.lam@apple.com>
554
555         Crash in JavaScriptCore GC when using JSC on dispatch queues (thread_get_state returns NULL stack pointer).
556         https://bugs.webkit.org/show_bug.cgi?id=160337
557         <rdar://problem/27611733>
558
559         Reviewed by Filip Pizlo and Geoffrey Garen.
560
561         This is a workaround for <rdar://problem/27607384>. During thread initialization,
562         for some target platforms, thread state is momentarily set to 0 before being
563         filled in with the target thread's real register values. As a result, there's
564         a race condition that may result in us getting a null stackPointer during a GC scan.
565         This issue may manifest with workqueue threads where the OS may choose to recycle
566         a thread for an expired task.
567
568         The workaround is simply to indicate that there's nothing to copy and return.
569         This is correct because we will only ever observe a null pointer during thread
570         initialization. Hence, by definition, there's nothing there that we need to scan
571         yet, and therefore, nothing that needs to be copied.
572
573         * heap/MachineStackMarker.cpp:
574         (JSC::MachineThreads::tryCopyOtherThreadStack):
575
576 2017-05-10  JF Bastien  <jfbastien@apple.com>
577
578         WebAssembly: support name section
579
580         https://bugs.webkit.org/show_bug.cgi?id=171263
581
582         Reviewed by Keith Miller.
583
584         The name section is an optional custom section in the WebAssembly
585         spec. At least when debugging, developers expect to be able to use
586         this section to obtain intelligible stack traces, otherwise we
587         just number the wasm functions which is somewhat painful.
588
589         This patch parses this section, dropping its content eagerly on
590         error, and if there is a name section then backtraces use their
591         value instead of numbers. Otherwise we stick to numbers as before.
592
593         Note that the format of name sections changed in mid-February:
594           https://github.com/WebAssembly/design/pull/984
595         And binaryen was only updated in early March:
596           https://github.com/WebAssembly/binaryen/pull/933
597
598         * CMakeLists.txt:
599         * JavaScriptCore.xcodeproj/project.pbxproj:
600         * interpreter/Interpreter.cpp:
601         (JSC::GetStackTraceFunctor::operator()):
602         * interpreter/StackVisitor.cpp:
603         (JSC::StackVisitor::readNonInlinedFrame):
604         (JSC::StackVisitor::Frame::functionName):
605         * interpreter/StackVisitor.h:
606         (JSC::StackVisitor::Frame::wasmFunctionIndexOrName):
607         * runtime/StackFrame.cpp:
608         (JSC::StackFrame::functionName):
609         * runtime/StackFrame.h:
610         (JSC::StackFrame::StackFrame):
611         (JSC::StackFrame::wasm):
612         * wasm/WasmBBQPlanInlines.h:
613         (JSC::Wasm::BBQPlan::initializeCallees):
614         * wasm/WasmCallee.cpp:
615         (JSC::Wasm::Callee::Callee):
616         * wasm/WasmCallee.h:
617         (JSC::Wasm::Callee::create):
618         (JSC::Wasm::Callee::indexOrName):
619         * wasm/WasmFormat.cpp:
620         (JSC::Wasm::makeString):
621         * wasm/WasmFormat.h:
622         (JSC::Wasm::isValidExternalKind):
623         (JSC::Wasm::isValidNameType):
624         (JSC::Wasm::NameSection::get):
625         * wasm/WasmIndexOrName.cpp: Copied from Source/JavaScriptCore/wasm/WasmCallee.cpp.
626         (JSC::Wasm::IndexOrName::IndexOrName):
627         (JSC::Wasm::makeString):
628         * wasm/WasmIndexOrName.h: Copied from Source/JavaScriptCore/wasm/WasmFormat.cpp.
629         * wasm/WasmModuleInformation.h:
630         * wasm/WasmModuleParser.cpp:
631         * wasm/WasmName.h: Copied from Source/JavaScriptCore/wasm/WasmCallee.cpp.
632         * wasm/WasmNameSectionParser.cpp: Added.
633         * wasm/WasmNameSectionParser.h: Copied from Source/JavaScriptCore/wasm/WasmCallee.cpp.
634         (JSC::Wasm::NameSectionParser::NameSectionParser):
635         * wasm/WasmOMGPlan.cpp:
636         (JSC::Wasm::OMGPlan::work):
637         * wasm/WasmParser.h:
638         (JSC::Wasm::Parser<SuccessType>::consumeUTF8String):
639
640 2017-05-10  Filip Pizlo  <fpizlo@apple.com>
641
642         Null pointer dereference in WTF::RefPtr<WTF::StringImpl>::operator!() under slow_path_get_direct_pname
643         https://bugs.webkit.org/show_bug.cgi?id=171801
644
645         Reviewed by Michael Saboff.
646         
647         This was a goofy oversight. The for-in optimization relies on the bytecode generator
648         to detect when the loop's index variable gets mutated. We forgot to have the hooks for
649         detecting this in prefix and postfix operations (++i and i++).
650
651         * bytecompiler/NodesCodegen.cpp:
652         (JSC::PostfixNode::emitResolve):
653         (JSC::PrefixNode::emitResolve):
654
655 2017-05-10  Michael Catanzaro  <mcatanzaro@igalia.com>
656
657         [GTK] -Wmissing-field-initializers triggered by RemoteInspectorServer.cpp:128
658         https://bugs.webkit.org/show_bug.cgi?id=171273
659
660         Reviewed by Carlos Garcia Campos.
661
662         * inspector/remote/glib/RemoteInspectorGlib.cpp:
663         * inspector/remote/glib/RemoteInspectorServer.cpp:
664
665 2017-05-10  Adrian Perez de Castro  <aperez@igalia.com>
666
667         Remove some last remnants of the EFL port
668         https://bugs.webkit.org/show_bug.cgi?id=171922
669
670         Reviewed by Antonio Gomes.
671
672         The EFL port is no more.
673
674         * PlatformEfl.cmake: Removed.
675         * shell/PlatformEfl.cmake: Removed.
676
677 2017-05-09  Filip Pizlo  <fpizlo@apple.com>
678
679         JSInjectedScriptHost should get a copy of the boundArgs
680         https://bugs.webkit.org/show_bug.cgi?id=171897
681
682         Reviewed by Joseph Pecoraro.
683         
684         The boundArgs array is very special - it cannot be mutated in any way. So, it makes sense
685         for the inspector to get a copy of it.
686
687         * inspector/JSInjectedScriptHost.cpp:
688         (Inspector::JSInjectedScriptHost::getInternalProperties):
689         * runtime/JSBoundFunction.cpp:
690         (JSC::JSBoundFunction::boundArgsCopy):
691         * runtime/JSBoundFunction.h:
692         (JSC::JSBoundFunction::boundArgs):
693
694 2017-05-09  Mark Lam  <mark.lam@apple.com>
695
696         Unindent some code in Watchdog::shouldTerminate().
697         https://bugs.webkit.org/show_bug.cgi?id=171896
698
699         Rubber stamped by Keith Miller.
700
701         I should have done this before I landed r213107, but I forgot.  Unindenting it now.
702
703         * runtime/Watchdog.cpp:
704         (JSC::Watchdog::shouldTerminate):
705
706 2017-05-09  Michael Saboff  <msaboff@apple.com>
707
708         Cap the number of FTL compilation threads on iOS to 2
709         https://bugs.webkit.org/show_bug.cgi?id=171887
710
711         Reviewed by Filip Pizlo.
712
713         Set an iOS specific max of 2 threads.
714
715         * runtime/Options.h:
716
717 2017-05-09  Filip Pizlo  <fpizlo@apple.com>
718
719         Heap::heap() should behave gracefully for null pointers
720         https://bugs.webkit.org/show_bug.cgi?id=171888
721         <rdar://problem/32005315>
722
723         Reviewed by Mark Lam.
724         
725         Some callers of Heap::heap() can pass a null cell and they will behave gracefully if we
726         return a null Heap. So, let's do that.
727         
728         This fixes a crash and it does not hurt performance. I'm seeing a possible 0.5% regression
729         with 74% probability. That's a neutral result by our usual 95% standard.
730
731         * heap/HeapInlines.h:
732         (JSC::Heap::heap):
733
734 2017-05-09  Yusuke Suzuki  <utatane.tea@gmail.com>
735
736         Handle IDLPromise<> properly
737         https://bugs.webkit.org/show_bug.cgi?id=166752
738
739         Reviewed by Youenn Fablet.
740
741         Add JSPromise::resolve static function.
742         This applies `Promise.resolve()` conversion to a given value.
743
744         * runtime/JSGlobalObject.cpp:
745         (JSC::JSGlobalObject::init):
746         (JSC::JSGlobalObject::visitChildren):
747         * runtime/JSGlobalObject.h:
748         (JSC::JSGlobalObject::promiseResolveFunction):
749         * runtime/JSPromise.cpp:
750         (JSC::JSPromise::resolve):
751         * runtime/JSPromise.h:
752
753 2017-05-09  Zan Dobersek  <zdobersek@igalia.com>
754
755         Upstream the WPE port
756         https://bugs.webkit.org/show_bug.cgi?id=171110
757
758         Reviewed by Alex Christensen.
759
760         * PlatformWPE.cmake: Added.
761         * shell/PlatformWPE.cmake: Added.
762
763 2017-05-09  Saam Barati  <sbarati@apple.com>
764
765         CallLinkInfos belonging to Wasm->JS stubs need to be informed when we clearCode() from all Executables
766         https://bugs.webkit.org/show_bug.cgi?id=171707
767         <rdar://problem/31891649>
768
769         Reviewed by Filip Pizlo.
770
771         This patch fixes a bug where a Wasm->JS IC call stub would go stale
772         and point into a CodeBlock no longer owned by any executable. The
773         problematic scenario is this:
774
775         1. We generate the call IC which has a branch on a callee check. This
776            callee owns the Executable in question. If the branch succeeds, it
777            will call code belonging to a particular CodeBlock associated with
778            that Executable.
779
780         2. Heap::deleteAllCodeBlocks is called. This leads the Executable to clear
781            its various CodeBlock references.
782
783         3. Wasm has no idea this happened, so now it has stale ICs that point into
784            code from a CodeBlock no longer belonging to an Executable.
785
786         This patch fixes the bug by informing all JSWebAssemblyCodeBlocks to unlink
787         their CallLinkInfo when Heap::deleteAllCodeBlocks is called.
788
789         We track all JSWebAssemblyCodeBlocks by creating a new subspace for them.
790         This allows us to quickly iterate over the live JSWebAssemblyCodeBlocks in the
791         heap.
792
793         * CMakeLists.txt:
794         * JavaScriptCore.xcodeproj/project.pbxproj:
795         * heap/Heap.cpp:
796         (JSC::Heap::deleteAllCodeBlocks):
797         * heap/Subspace.h:
798         * heap/SubspaceInlines.h:
799         (JSC::Subspace::forEachLiveCell):
800         * runtime/VM.cpp:
801         (JSC::VM::VM):
802         * runtime/VM.h:
803         * wasm/js/JSWebAssemblyCodeBlock.cpp:
804         (JSC::JSWebAssemblyCodeBlock::clearJSCallICs):
805         * wasm/js/JSWebAssemblyCodeBlock.h:
806         (JSC::JSWebAssemblyCodeBlock::createStructure): Deleted.
807         (JSC::JSWebAssemblyCodeBlock::functionImportCount): Deleted.
808         (JSC::JSWebAssemblyCodeBlock::module): Deleted.
809         (JSC::JSWebAssemblyCodeBlock::jsEntrypointCalleeFromFunctionIndexSpace): Deleted.
810         (JSC::JSWebAssemblyCodeBlock::wasmEntrypointLoadLocationFromFunctionIndexSpace): Deleted.
811         (JSC::JSWebAssemblyCodeBlock::wasmToJsCallStubForImport): Deleted.
812         (JSC::JSWebAssemblyCodeBlock::offsetOfImportWasmToJSStub): Deleted.
813         (JSC::JSWebAssemblyCodeBlock::codeBlock): Deleted.
814         (JSC::JSWebAssemblyCodeBlock::offsetOfImportStubs): Deleted.
815         (JSC::JSWebAssemblyCodeBlock::allocationSize): Deleted.
816         (JSC::JSWebAssemblyCodeBlock::importWasmToJSStub): Deleted.
817         * wasm/js/JSWebAssemblyCodeBlockSubspace.cpp: Added.
818         (JSC::JSWebAssemblyCodeBlockSubspace::JSWebAssemblyCodeBlockSubspace):
819         (JSC::JSWebAssemblyCodeBlockSubspace::~JSWebAssemblyCodeBlockSubspace):
820         (JSC::JSWebAssemblyCodeBlockSubspace::finishSweep):
821         (JSC::JSWebAssemblyCodeBlockSubspace::destroy):
822         * wasm/js/JSWebAssemblyCodeBlockSubspace.h: Added.
823
824 2017-05-08  Saam Barati  <sbarati@apple.com>
825
826         testWasmBoundsCheck and testCallFunctionWithHellaArguments is broken in testb3
827         https://bugs.webkit.org/show_bug.cgi?id=171392
828         <rdar://problem/31872222>
829
830         Reviewed by Keith Miller.
831
832         This patch fixes two bugs. The first one is:
833         Inside testb3, we were using the wrong WasmBoundsCheckValue constructor.
834         Everything compiled OK because of implicit casting in C. I've changed one
835         of the constructors to take arguments in a different order so we don't
836         run into this problem again.
837         
838         The second bug was that Air::ShufflePair::inst was assuming that a move
839         from BigImm to its destination is always valid. This is not the case.
840         For example, the store, `Move BigImm, Addr` is not allowed. I refactored
841         the code to be correct by emitting more than one instruction when needeed.
842         
843         When testing my changes, I ran ARM64 testb3 both in debug and
844         release. I ran into many pre-existing failures. I've opened
845         a new bug to fix those here: https://bugs.webkit.org/show_bug.cgi?id=171826
846
847         * b3/B3WasmBoundsCheckValue.cpp:
848         (JSC::B3::WasmBoundsCheckValue::WasmBoundsCheckValue):
849         * b3/B3WasmBoundsCheckValue.h:
850         * b3/air/AirEmitShuffle.cpp:
851         (JSC::B3::Air::ShufflePair::insts):
852         (JSC::B3::Air::ShufflePair::inst): Deleted.
853         * b3/air/AirEmitShuffle.h:
854         * b3/air/AirLowerMacros.cpp:
855         (JSC::B3::Air::lowerMacros):
856         * b3/testb3.cpp:
857         (JSC::B3::testLoadAcq42):
858         (JSC::B3::testStoreRelAddLoadAcq32):
859         (JSC::B3::testStoreRelAddLoadAcq8):
860         (JSC::B3::testStoreRelAddFenceLoadAcq8):
861         (JSC::B3::testStoreRelAddLoadAcq16):
862         (JSC::B3::testStoreRelAddLoadAcq64):
863         (JSC::B3::testSimplePatchpointWithOuputClobbersGPArgs):
864         (JSC::B3::testCheckMul):
865         (JSC::B3::testCheckMulMemory):
866         (JSC::B3::testCheckMul64):
867         (JSC::B3::testCheckMulFold):
868         (JSC::B3::testCheckMulFoldFail):
869         (JSC::B3::testCheckMulArgumentAliasing64):
870         (JSC::B3::testCheckMulArgumentAliasing32):
871         (JSC::B3::testCheckMul64SShr):
872         (JSC::B3::testCallFunctionWithHellaArguments):
873         (JSC::B3::functionWithHellaArguments2):
874         (JSC::B3::testCallFunctionWithHellaArguments2):
875         (JSC::B3::functionWithHellaArguments3):
876         (JSC::B3::testCallFunctionWithHellaArguments3):
877         (JSC::B3::testSpillDefSmallerThanUse):
878         (JSC::B3::testLateRegister):
879         (JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled):
880         (JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled2):
881         (JSC::B3::testMoveConstants):
882         (JSC::B3::testAtomicWeakCAS):
883         (JSC::B3::testAtomicStrongCAS):
884         (JSC::B3::testAtomicXchg):
885         (JSC::B3::testWasmBoundsCheck):
886         (JSC::B3::run):
887         * wasm/WasmB3IRGenerator.cpp:
888         (JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer):
889
890 2017-05-08  Filip Pizlo  <fpizlo@apple.com>
891
892         Expose a function to get proxy targets
893         https://bugs.webkit.org/show_bug.cgi?id=171797
894         <rdar://problem/32027549>
895
896         Reviewed by Mark Lam.
897         
898         This exposes a new private API function, JSObjectGetProxyTarget(), that gets the target of a
899         proxy. It works with both ProxyObject and JSProxy, but it's primarily intended for use with
900         JSProxy.
901
902         * API/JSObjectRef.cpp:
903         (JSObjectGetProxyTarget):
904         * API/JSObjectRefPrivate.h:
905         * API/tests/JSObjectGetProxyTargetTest.cpp: Added.
906         (testJSObjectGetProxyTarget):
907         * API/tests/JSObjectGetProxyTargetTest.h: Added.
908         * API/tests/testapi.c:
909         (main):
910         * JavaScriptCore.xcodeproj/project.pbxproj:
911         * runtime/ProxyObject.h:
912         * shell/PlatformWin.cmake: 
913
914 2017-05-08  Mark Lam  <mark.lam@apple.com>
915
916         op_throw_static_error's use of its first operand should be reflected in DFG BytecodeUseDef as well.
917         https://bugs.webkit.org/show_bug.cgi?id=171786
918         <rdar://problem/32051023>
919
920         Reviewed by Saam Barati.
921
922         * bytecode/BytecodeDumper.cpp:
923         (JSC::BytecodeDumper<Block>::dumpBytecode):
924         - Fix BytecodeDumper to dump op_throw_static_error correctly.  Previously,
925           it was expecting op1 to always be a constant.  r206870 changed it to take a
926           variable string as well.
927
928         * bytecode/BytecodeUseDef.h:
929         (JSC::computeUsesForBytecodeOffset):
930         - Fix the bug.
931
932         * dfg/DFGByteCodeParser.cpp:
933         (JSC::DFG::ByteCodeParser::parseBlock):
934         - Move the Phantom of op1 after the ThrowStaticError node, because technically,
935           the ThrowStaticError represents op_throw_static_error, and op_throw_static_error
936           uses op1.  In practice, this probably doesn't matter, but let's have the code
937           accurately communicate the behavior we're expecting.
938
939 2017-05-08  JF Bastien  <jfbastien@apple.com>
940
941         WebAssembly: don't just emit extended offset adds for patch
942         https://bugs.webkit.org/show_bug.cgi?id=171799
943
944         Reviewed by Mark Lam.
945
946         It isn't necessary to restrict.
947
948         * b3/air/AirLowerStackArgs.cpp:
949         (JSC::B3::Air::lowerStackArgs):
950
951 2017-05-08  Mark Lam  <mark.lam@apple.com>
952
953         Introduce ExceptionScope::assertNoException() and releaseAssertNoException().
954         https://bugs.webkit.org/show_bug.cgi?id=171776
955
956         Reviewed by Keith Miller.
957
958         Instead of ASSERT(!scope.exception()), we can now do scope.assertNoException().
959         Ditto for RELEASE_ASSERT and scope.releaseAssertNoException().  
960
961         The advantage of using ExceptionScope::assertNoException() and
962         releaseAssertNoException() is that if the assertion fails, these utility
963         functions will print the stack trace for where the unexpected exception is
964         detected as well as where the unexpected exception was thrown from.  This makes
965         it much easier to debug the source of unhandled exceptions.
966
967         * debugger/Debugger.cpp:
968         (JSC::Debugger::pauseIfNeeded):
969         * dfg/DFGOperations.cpp:
970         * interpreter/Interpreter.cpp:
971         (JSC::eval):
972         (JSC::notifyDebuggerOfUnwinding):
973         (JSC::Interpreter::executeProgram):
974         (JSC::Interpreter::executeCall):
975         (JSC::Interpreter::executeConstruct):
976         (JSC::Interpreter::prepareForRepeatCall):
977         (JSC::Interpreter::execute):
978         (JSC::Interpreter::debug):
979         * interpreter/ShadowChicken.cpp:
980         (JSC::ShadowChicken::functionsOnStack):
981         * jsc.cpp:
982         (GlobalObject::moduleLoaderResolve):
983         (GlobalObject::moduleLoaderFetch):
984         (functionGenerateHeapSnapshot):
985         (functionSamplingProfilerStackTraces):
986         (box):
987         (runWithScripts):
988         * runtime/AbstractModuleRecord.cpp:
989         (JSC::AbstractModuleRecord::finishCreation):
990         * runtime/ArrayPrototype.cpp:
991         (JSC::ArrayPrototype::tryInitializeSpeciesWatchpoint):
992         * runtime/Completion.cpp:
993         (JSC::rejectPromise):
994         * runtime/ErrorInstance.cpp:
995         (JSC::ErrorInstance::sanitizedToString):
996         * runtime/ExceptionHelpers.cpp:
997         (JSC::createError):
998         * runtime/ExceptionScope.cpp:
999         (JSC::ExceptionScope::unexpectedExceptionMessage):
1000         * runtime/ExceptionScope.h:
1001         (JSC::ExceptionScope::assertNoException):
1002         (JSC::ExceptionScope::releaseAssertNoException):
1003         (JSC::ExceptionScope::unexpectedExceptionMessage):
1004         * runtime/GenericArgumentsInlines.h:
1005         (JSC::GenericArguments<Type>::defineOwnProperty):
1006         * runtime/IntlCollator.cpp:
1007         (JSC::IntlCollator::createCollator):
1008         (JSC::IntlCollator::resolvedOptions):
1009         * runtime/IntlDateTimeFormat.cpp:
1010         (JSC::IntlDateTimeFormat::resolvedOptions):
1011         (JSC::IntlDateTimeFormat::format):
1012         * runtime/IntlNumberFormat.cpp:
1013         (JSC::IntlNumberFormat::createNumberFormat):
1014         (JSC::IntlNumberFormat::resolvedOptions):
1015         * runtime/JSCJSValue.cpp:
1016         (JSC::JSValue::putToPrimitiveByIndex):
1017         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
1018         (JSC::genericTypedArrayViewProtoFuncIncludes):
1019         (JSC::genericTypedArrayViewProtoFuncIndexOf):
1020         (JSC::genericTypedArrayViewProtoFuncLastIndexOf):
1021         (JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
1022         * runtime/JSGlobalObject.cpp:
1023         (JSC::JSGlobalObject::init):
1024         * runtime/JSGlobalObjectFunctions.cpp:
1025         (JSC::globalFuncHostPromiseRejectionTracker):
1026         * runtime/JSModuleEnvironment.cpp:
1027         (JSC::JSModuleEnvironment::getOwnPropertySlot):
1028         * runtime/JSModuleLoader.cpp:
1029         (JSC::JSModuleLoader::finishCreation):
1030         * runtime/JSModuleNamespaceObject.cpp:
1031         (JSC::JSModuleNamespaceObject::finishCreation):
1032         * runtime/JSONObject.cpp:
1033         (JSC::Stringifier::toJSON):
1034         * runtime/JSObject.cpp:
1035         (JSC::JSObject::ordinaryToPrimitive):
1036         * runtime/JSPropertyNameEnumerator.h:
1037         (JSC::propertyNameEnumerator):
1038         * runtime/ObjectConstructor.cpp:
1039         (JSC::objectConstructorGetOwnPropertyDescriptors):
1040         (JSC::objectConstructorDefineProperty):
1041         * runtime/ObjectPrototype.cpp:
1042         (JSC::objectProtoFuncHasOwnProperty):
1043         * runtime/ProgramExecutable.cpp:
1044         (JSC::ProgramExecutable::initializeGlobalProperties):
1045         * runtime/ReflectObject.cpp:
1046         (JSC::reflectObjectDefineProperty):
1047         * runtime/SamplingProfiler.cpp:
1048         (JSC::SamplingProfiler::StackFrame::nameFromCallee):
1049         * runtime/StringPrototype.cpp:
1050         (JSC::stringProtoFuncRepeatCharacter):
1051         * runtime/TemplateRegistry.cpp:
1052         (JSC::TemplateRegistry::getTemplateObject):
1053         * runtime/VM.cpp:
1054         (JSC::VM::throwException):
1055         * runtime/VM.h:
1056         (JSC::VM::nativeStackTraceOfLastThrow):
1057         (JSC::VM::clearException):
1058         * wasm/WasmB3IRGenerator.cpp:
1059         * wasm/js/JSWebAssemblyInstance.cpp:
1060         (JSC::JSWebAssemblyInstance::create):
1061
1062 2017-05-06  Bill Ming  <mbbill@gmail.com>
1063
1064         Fix 32bit Windows build by giving correct parameters to MASM
1065         https://bugs.webkit.org/show_bug.cgi?id=170833
1066
1067         Reviewed by Alex Christensen.
1068
1069         * CMakeLists.txt:
1070
1071 2017-05-06  Oleksandr Skachkov  <gskachkov@gmail.com>
1072
1073         [ES6] Arrow function. Issue in access to this after eval('super()') within constructor
1074         https://bugs.webkit.org/show_bug.cgi?id=171543
1075
1076         Reviewed by Saam Barati.
1077
1078         Current patch force to use 'this' within arrow function or eval 
1079         from virtual scope each time, instead of using thisRegister.
1080
1081         * bytecompiler/BytecodeGenerator.cpp:
1082         (JSC::BytecodeGenerator::ensureThis):
1083
1084 2017-05-05  Keith Miller  <keith_miller@apple.com>
1085
1086         Put does not properly consult the prototype chain
1087         https://bugs.webkit.org/show_bug.cgi?id=171754
1088
1089         Reviewed by Saam Barati.
1090
1091         We should do a follow up that cleans up the rest of put. See:
1092         https://bugs.webkit.org/show_bug.cgi?id=171759
1093
1094         * runtime/JSCJSValue.cpp:
1095         (JSC::JSValue::putToPrimitive):
1096         * runtime/JSObject.cpp:
1097         (JSC::JSObject::putInlineSlow):
1098         * runtime/JSObjectInlines.h:
1099         (JSC::JSObject::canPerformFastPutInline):
1100
1101 2017-05-05  JF Bastien  <jfbastien@apple.com>
1102
1103         WebAssembly: Air::Inst::generate crashes on large binary on A64
1104         https://bugs.webkit.org/show_bug.cgi?id=170215
1105
1106         Reviewed by Filip Pizlo.
1107
1108         ARM can't encode all offsets in a single instruction. We usualy
1109         handle this type of detail early, or the macro assembler uses a
1110         scratch register to take care of the large immediate. After
1111         register allocation we assumed that we would never get large
1112         offsets, and asserted this was the case. That was a fine
1113         assumption with JavaScript, but WebAssembly ends up generating
1114         stack frames which are too big to encode.
1115
1116         There are two places that needed to be fixed:
1117             1. AirGenerate
1118             2. AirLowerStackArgs
1119
1120         We now unconditionally pin the dataTempRegister on ARM64, and use
1121         it when immediates don't fit.
1122
1123         Number 1. is easy: we're just incrementing SP, make sure we can
1124         use a scratch register when that happens.
1125
1126         Number 2. is more complex: not all Inst can receive a stack
1127         argument whose base register isn't SP or FP. Specifically,
1128         Patchpoints and Stackmaps get very sad because they just want to
1129         know the offset value, but when we materialize the offset as
1130         follows:
1131
1132             Move (spill337), (spill201), %r0, @8735
1133
1134         Becomes (where %r16 is dataTempRegister):
1135             Move $1404, %r16, @8736
1136             Add64 %sp, %r16, @8736
1137             Move (%r16), 2032(%sp), %r0, @8736
1138
1139         The code currently doesn't see through our little dance. To work
1140         around this issue we introduce a new Air Arg kind:
1141         ExtendedOffsetAddr. This is the same as a regular Addr, but with
1142         an offset which may be too big to encode. Opcodes then declare
1143         whether their arguments can handle such inputs, and if so we
1144         generate them, otherwise we generate Addr as shown above.
1145
1146         None of this affects x86 because it can always encode large
1147         immediates.
1148
1149         This patch also drive-by converts some uses of `override` to
1150         `final`. It makes the code easier to grok, and maybe helps the
1151         optimizer sometimes but really that doens't matter.
1152
1153         * assembler/MacroAssembler.h:
1154         * assembler/MacroAssemblerARM64.h:
1155         * b3/B3CheckSpecial.cpp:
1156         (JSC::B3::CheckSpecial::admitsExtendedOffsetAddr):
1157         * b3/B3CheckSpecial.h:
1158         * b3/B3Common.cpp:
1159         (JSC::B3::pinnedExtendedOffsetAddrRegister): keep the CPU-specific
1160         pinning information in a cpp file
1161         * b3/B3Common.h:
1162         * b3/B3PatchpointSpecial.cpp:
1163         (JSC::B3::PatchpointSpecial::admitsExtendedOffsetAddr):
1164         * b3/B3PatchpointSpecial.h:
1165         * b3/B3StackmapSpecial.cpp:
1166         (JSC::B3::StackmapSpecial::isArgValidForRep):
1167         (JSC::B3::StackmapSpecial::repForArg):
1168         * b3/B3StackmapSpecial.h:
1169         * b3/air/AirArg.cpp:
1170         (JSC::B3::Air::Arg::isStackMemory):
1171         (JSC::B3::Air::Arg::jsHash):
1172         (JSC::B3::Air::Arg::dump):
1173         (WTF::printInternal):
1174         (JSC::B3::Air::Arg::stackAddrImpl): Deleted. There was only one
1175         use of this (in AirLowerStackArgs) and it was now confusing to
1176         split the logic up between these two. Inline the code that used to
1177         be here into its one usepoint instead.
1178         * b3/air/AirArg.h:
1179         (JSC::B3::Air::Arg::extendedOffsetAddr):
1180         (JSC::B3::Air::Arg::isExtendedOffsetAddr):
1181         (JSC::B3::Air::Arg::isMemory):
1182         (JSC::B3::Air::Arg::base):
1183         (JSC::B3::Air::Arg::offset):
1184         (JSC::B3::Air::Arg::isGP):
1185         (JSC::B3::Air::Arg::isFP):
1186         (JSC::B3::Air::Arg::isValidForm):
1187         (JSC::B3::Air::Arg::forEachTmpFast):
1188         (JSC::B3::Air::Arg::forEachTmp):
1189         (JSC::B3::Air::Arg::asAddress):
1190         (JSC::B3::Air::Arg::stackAddr): Deleted.
1191         * b3/air/AirCCallSpecial.cpp:
1192         (JSC::B3::Air::CCallSpecial::isValid):
1193         (JSC::B3::Air::CCallSpecial::admitsExtendedOffsetAddr):
1194         (JSC::B3::Air::CCallSpecial::generate):
1195         * b3/air/AirCCallSpecial.h:
1196         * b3/air/AirCode.cpp:
1197         (JSC::B3::Air::Code::Code):
1198         (JSC::B3::Air::Code::pinRegister): Check that the register wasn't
1199         pinned before pinning it. It's likely a bug to pin the same
1200         register twice.
1201         * b3/air/AirCustom.h:
1202         (JSC::B3::Air::PatchCustom::admitsExtendedOffsetAddr):
1203         (JSC::B3::Air::CCallCustom::admitsExtendedOffsetAddr):
1204         (JSC::B3::Air::ShuffleCustom::admitsExtendedOffsetAddr):
1205         (JSC::B3::Air::EntrySwitchCustom::admitsExtendedOffsetAddr):
1206         (JSC::B3::Air::WasmBoundsCheckCustom::admitsExtendedOffsetAddr):
1207         * b3/air/AirGenerate.cpp:
1208         (JSC::B3::Air::generate):
1209         * b3/air/AirInst.h:
1210         * b3/air/AirInstInlines.h:
1211         (JSC::B3::Air::Inst::admitsExtendedOffsetAddr):
1212         * b3/air/AirLowerStackArgs.cpp:
1213         (JSC::B3::Air::lowerStackArgs):
1214         * b3/air/AirPrintSpecial.cpp:
1215         (JSC::B3::Air::PrintSpecial::admitsExtendedOffsetAddr):
1216         (JSC::B3::Air::PrintSpecial::generate):
1217         * b3/air/AirPrintSpecial.h:
1218         * b3/air/AirSpecial.h:
1219         * b3/air/opcode_generator.rb:
1220
1221 2017-05-05  Oliver Hunt  <oliver@apple.com>
1222
1223         Move trivial String prototype functions to JS builtins
1224         https://bugs.webkit.org/show_bug.cgi?id=171737
1225
1226         Reviewed by Saam Barati.
1227
1228         Super simple change to migrate all of the old school
1229         html-ifying string operations to builtin JS.
1230
1231         Core implementation is basically a 1-for-1 match to the spec.
1232
1233         * builtins/StringPrototype.js:
1234         (globalPrivate.createHTML):
1235         (anchor):
1236         (big):
1237         (blink):
1238         (bold):
1239         (fixed):
1240         (fontcolor):
1241         (fontsize):
1242         (italics):
1243         (link):
1244         (small):
1245         (strike):
1246         (sub):
1247         (sup):
1248         * runtime/StringPrototype.cpp:
1249         (JSC::StringPrototype::finishCreation):
1250         (JSC::stringProtoFuncBig): Deleted.
1251         (JSC::stringProtoFuncSmall): Deleted.
1252         (JSC::stringProtoFuncBlink): Deleted.
1253         (JSC::stringProtoFuncBold): Deleted.
1254         (JSC::stringProtoFuncFixed): Deleted.
1255         (JSC::stringProtoFuncItalics): Deleted.
1256         (JSC::stringProtoFuncStrike): Deleted.
1257         (JSC::stringProtoFuncSub): Deleted.
1258         (JSC::stringProtoFuncSup): Deleted.
1259         (JSC::stringProtoFuncFontcolor): Deleted.
1260         (JSC::stringProtoFuncFontsize): Deleted.
1261         (JSC::stringProtoFuncAnchor): Deleted.
1262         (JSC::stringProtoFuncLink): Deleted.
1263
1264 2017-05-05  Don Olmstead  <don.olmstead@am.sony.com>
1265
1266         [JSC] Remove export from Intrinsic
1267         https://bugs.webkit.org/show_bug.cgi?id=171752
1268
1269         Reviewed by Alexey Proskuryakov.
1270
1271         * runtime/Intrinsic.h:
1272
1273 2017-05-05  Saam Barati  <sbarati@apple.com>
1274
1275         putDirectIndex does not properly do defineOwnProperty
1276         https://bugs.webkit.org/show_bug.cgi?id=171591
1277         <rdar://problem/31735695>
1278
1279         Reviewed by Geoffrey Garen.
1280
1281         This patch fixes putDirectIndex and its JIT implementations to be
1282         compatible with the ES6 spec. I think our code became out of date
1283         when we implemented ArraySpeciesCreate since ArraySpeciesCreate may
1284         return arbitrary objects. We perform putDirectIndex on that arbitrary
1285         object. The behavior we want is as if we performed defineProperty({configurable:true, enumerable:true, writable:true}).
1286         However, we weren't doing this. putDirectIndex assumed it could just splat
1287         data into any descendent of JSObject's butterfly. For example, this means
1288         we'd just splat into the butterfly of a typed array, even though a typed
1289         array doesn't use its butterfly to store its indexed properties in the usual
1290         way. Also, typed array properties are non-configurable, so this operation
1291         should throw. This also means if we saw a ProxyObject, we'd just splat
1292         into its butterfly, but this is obviously wrong because ProxyObject should
1293         intercept the defineProperty operation.
1294         
1295         This patch fixes this issue by adding a whitelist of cell types that can
1296         go down putDirectIndex's fast path. Anything not in that whitelist will
1297         simply call into defineOwnProperty.
1298
1299         * bytecode/ByValInfo.h:
1300         (JSC::jitArrayModePermitsPutDirect):
1301         * dfg/DFGArrayMode.cpp:
1302         (JSC::DFG::ArrayMode::refine):
1303         * jit/JITOperations.cpp:
1304         * runtime/ArrayPrototype.cpp:
1305         (JSC::arrayProtoFuncSplice):
1306         * runtime/ClonedArguments.cpp:
1307         (JSC::ClonedArguments::createStructure):
1308         * runtime/JSGenericTypedArrayViewInlines.h:
1309         (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
1310         * runtime/JSObject.cpp:
1311         (JSC::canDoFastPutDirectIndex):
1312         (JSC::JSObject::defineOwnIndexedProperty):
1313         (JSC::JSObject::putDirectIndexSlowOrBeyondVectorLength):
1314         (JSC::JSObject::putDirectIndexBeyondVectorLength): Deleted.
1315         * runtime/JSObject.h:
1316         (JSC::JSObject::putDirectIndex):
1317         (JSC::JSObject::canSetIndexQuicklyForPutDirect): Deleted.
1318         * runtime/JSType.h:
1319
1320 2017-05-05  Guillaume Emont  <guijemont@igalia.com>
1321
1322         [JSC] include JSCInlines.h in ObjectInitializationScope.cpp
1323         https://bugs.webkit.org/show_bug.cgi?id=171744
1324
1325         Reviewed by Mark Lam.
1326
1327         * runtime/ObjectInitializationScope.cpp:
1328
1329
1330 2017-05-05  Carlos Garcia Campos  <cgarcia@igalia.com>
1331
1332         [GTK] Assertion failure in Inspector::RemoteInspector::setRemoteInspectorClient when disposing WebKitWebContext
1333         https://bugs.webkit.org/show_bug.cgi?id=171644
1334
1335         Reviewed by Michael Catanzaro.
1336
1337         Fix ASSERT that requires given client to be a valid pointer, since it's valid to pass nullptr to unset the
1338         client. The ASSERT now ensures that client is set or unset. I also renamed the function to setClient because
1339         setRemoteInspectorClient is redundant for a class named RemoteInspector. And added a getter too, to check if the
1340         remote inspector has a client.
1341
1342         * inspector/remote/RemoteInspector.cpp:
1343         (Inspector::RemoteInspector::setClient):
1344         * inspector/remote/RemoteInspector.h:
1345
1346 2017-05-04  Commit Queue  <commit-queue@webkit.org>
1347
1348         Unreviewed, rolling out r216206.
1349         https://bugs.webkit.org/show_bug.cgi?id=171714
1350
1351         Multiple LayoutTests crashing in Document::page() (Requested
1352         by ap on #webkit).
1353
1354         Reverted changeset:
1355
1356         "Remove support for legacy Notifications"
1357         https://bugs.webkit.org/show_bug.cgi?id=171487
1358         http://trac.webkit.org/changeset/216206
1359
1360 2017-05-04  Don Olmstead  <don.olmstead@am.sony.com>
1361
1362         [Win] Remove redundant macros that are set in the CMake config
1363         https://bugs.webkit.org/show_bug.cgi?id=171571
1364
1365         Reviewed by Brent Fulgham.
1366
1367         * config.h:
1368
1369 2017-05-04  Mark Lam  <mark.lam@apple.com>
1370
1371         Gardening: Build fix for Windows after r216217.
1372         https://bugs.webkit.org/show_bug.cgi?id=171586
1373
1374         Not reviewed.
1375
1376         * shell/PlatformWin.cmake:
1377
1378 2017-05-04  Filip Pizlo  <fpizlo@apple.com>
1379
1380         JSC::Heap should expose a richer API for requesting GCs
1381         https://bugs.webkit.org/show_bug.cgi?id=171690
1382
1383         Reviewed by Geoffrey Garen.
1384         
1385         I want to stop WebCore from requesting synchronous GCs. But various parts of that work
1386         may cause regressions, so I'd like to land it separately from the functionality that is
1387         needed on the JSC side. This change is mostly a JSC-side refactoring that does not
1388         change behavior. In the future I'll land the behavior changes (i.e. not requesting sync
1389         GCs).
1390         
1391         This change allows you to enumerate over synchronousness, so that we can make all APIs
1392         take synchronousness as an argument. It replaces the collectAllGarbage API with a
1393         collectNow(Synchronousness, GCRequest) API. GCRequest is a new concept, which subsumes
1394         std::optional<CollectionScope> and gives us the ability to register callbacks along
1395         with a GC. So, you can ask for an async GC and get a callback when it's done.
1396         
1397         Also adds ability to request that fastMalloc memory be released after the incremental
1398         sweeper finishes.
1399         
1400         * API/JSBase.cpp:
1401         (JSSynchronousGarbageCollectForDebugging):
1402         * CMakeLists.txt:
1403         * JavaScriptCore.xcodeproj/project.pbxproj:
1404         * heap/FullGCActivityCallback.cpp:
1405         (JSC::FullGCActivityCallback::doCollection):
1406         * heap/FullGCActivityCallback.h:
1407         * heap/GCRequest.cpp: Added.
1408         (JSC::GCRequest::subsumedBy):
1409         (JSC::GCRequest::dump):
1410         * heap/GCRequest.h: Added.
1411         (JSC::GCRequest::GCRequest):
1412         * heap/Heap.cpp:
1413         (JSC::Heap::collect):
1414         (JSC::Heap::collectNow):
1415         (JSC::Heap::collectAsync):
1416         (JSC::Heap::collectSync):
1417         (JSC::Heap::runBeginPhase):
1418         (JSC::Heap::runEndPhase):
1419         (JSC::Heap::requestCollection):
1420         (JSC::Heap::willStartCollection):
1421         (JSC::Heap::sweeper):
1422         (JSC::Heap::collectNowFullIfNotDoneRecently):
1423         (JSC::Heap::shouldDoFullCollection):
1424         (JSC::Heap::collectAllGarbage): Deleted.
1425         (JSC::Heap::collectAllGarbageIfNotDoneRecently): Deleted.
1426         * heap/Heap.h:
1427         * heap/HeapSnapshotBuilder.cpp:
1428         (JSC::HeapSnapshotBuilder::buildSnapshot):
1429         * heap/IncrementalSweeper.cpp:
1430         (JSC::IncrementalSweeper::doSweep):
1431         * heap/IncrementalSweeper.h:
1432         (JSC::IncrementalSweeper::freeFastMallocMemoryAfterSweeping):
1433         * heap/MarkedAllocator.cpp:
1434         (JSC::MarkedAllocator::doTestCollectionsIfNeeded):
1435         * heap/MarkedSpace.cpp:
1436         (JSC::MarkedSpace::sweep):
1437         * heap/Synchronousness.cpp: Added.
1438         (WTF::printInternal):
1439         * heap/Synchronousness.h: Added.
1440         * inspector/agents/InspectorHeapAgent.cpp:
1441         (Inspector::InspectorHeapAgent::gc):
1442         * jsc.cpp:
1443         (functionGCAndSweep):
1444         (runJSC):
1445         * tools/JSDollarVMPrototype.cpp:
1446         (JSC::JSDollarVMPrototype::gc):
1447         * wasm/WasmMemory.cpp:
1448
1449 2017-05-04  Mark Lam  <mark.lam@apple.com>
1450
1451         NeverDestroyed<String>(ASCIILiteral(...)) is not thread safe.
1452         https://bugs.webkit.org/show_bug.cgi?id=171586
1453         <rdar://problem/31873190>
1454
1455         Reviewed by Yusuke Suzuki.
1456
1457         JavaScriptCore allows multiple VMs to be instantiated, and each of these should
1458         be able to run concurrently on different threads.  There is code in the VM that
1459         allocates NeverDestroyed<String>(ASCIILiteral(...)) to defined immortal strings
1460         meant to be shared by all VMs.
1461
1462         However, NeverDestroyed<String>(ASCIILiteral(...)) is not thread-safe because
1463         each thread will ref and deref the underlying StringImpl.  Since this ref and
1464         deref is not done in a thread-safe way, the NeverDestroyed<String> may get
1465         destroyed due to the ref/deref races.  Additionally, each thread may modify the
1466         StringImpl by setting its hash and also twiddling its flags.
1467
1468         The fix is to use the StaticStringImpl class which is safe for ref/derefing
1469         concurrently from different threads.  StaticStringImpl is also pre-set with a
1470         hash on construction, and its flags are set in such a way as to prevent twiddling
1471         at runtime.  Hence, we will be able to share a NeverDestroyed<String> between
1472         VMs, as long as it is backed by a StaticStringImpl.
1473
1474         An alternative solution would be to change all the uses of NeverDestroyed<String>
1475         to use per-VM strings.  However, this solution is cumbersome, and makes it harder
1476         to allocate the intended shared string.  It also uses more memory and takes more
1477         CPU time because it requires allocating the same string for each VM instance.
1478         The StaticStringImpl solution wins out because it is more efficient and is easier
1479         to use.
1480
1481         The StaticStringImpl solution also can be used in WTF without a layer violation.
1482         See Source/WTF/wtf/text/icu/TextBreakIteratorICU.h for an example.
1483
1484         Also added the MultithreadedMultiVMExecutionTest which runs multiple VMs in
1485         multiple threads, all banging on the BuiltinExecutable's baseConstructorCode
1486         NeverDestroyed<String>.  The test will manifest the issue reliably (before this
1487         fix) if run on an ASAN build.
1488
1489         * API/tests/MultithreadedMultiVMExecutionTest.cpp: Added.
1490         (threadsList):
1491         (startMultithreadedMultiVMExecutionTest):
1492         (finalizeMultithreadedMultiVMExecutionTest):
1493         * API/tests/MultithreadedMultiVMExecutionTest.h: Added.
1494         * API/tests/testapi.c:
1495         (main):
1496         * JavaScriptCore.xcodeproj/project.pbxproj:
1497         * builtins/BuiltinExecutables.cpp:
1498         (JSC::BuiltinExecutables::createDefaultConstructor):
1499         * inspector/agents/InspectorDebuggerAgent.cpp:
1500         (Inspector::objectGroupForBreakpointAction):
1501         * replay/scripts/CodeGeneratorReplayInputsTemplates.py:
1502         * replay/scripts/tests/expected/generate-enum-encoding-helpers-with-guarded-values.json-TestReplayInputs.cpp:
1503         (JSC::InputTraits<Test::SavedMouseButton>::type):
1504         * replay/scripts/tests/expected/generate-enum-encoding-helpers.json-TestReplayInputs.cpp:
1505         (JSC::InputTraits<Test::SavedMouseButton>::type):
1506         * replay/scripts/tests/expected/generate-enum-with-guard.json-TestReplayInputs.cpp:
1507         (JSC::InputTraits<Test::HandleWheelEvent>::type):
1508         * replay/scripts/tests/expected/generate-enums-with-same-base-name.json-TestReplayInputs.cpp:
1509         (JSC::InputTraits<Test::FormCombo>::type):
1510         * replay/scripts/tests/expected/generate-input-with-guard.json-TestReplayInputs.cpp:
1511         (JSC::InputTraits<Test::GetCurrentTime>::type):
1512         (JSC::InputTraits<Test::SetRandomSeed>::type):
1513         * replay/scripts/tests/expected/generate-input-with-vector-members.json-TestReplayInputs.cpp:
1514         (JSC::InputTraits<Test::ArrayOfThings>::type):
1515         (JSC::InputTraits<Test::SavedHistory>::type):
1516         * replay/scripts/tests/expected/generate-inputs-with-flags.json-TestReplayInputs.cpp:
1517         (JSC::InputTraits<Test::ScalarInput1>::type):
1518         (JSC::InputTraits<Test::ScalarInput2>::type):
1519         * replay/scripts/tests/expected/generate-memoized-type-modes.json-TestReplayInputs.cpp:
1520         (JSC::InputTraits<Test::ScalarInput>::type):
1521         (JSC::InputTraits<Test::MapInput>::type):
1522         * runtime/IntlObject.cpp:
1523         (JSC::numberingSystemsForLocale):
1524
1525 2017-05-04  Sam Weinig  <sam@webkit.org>
1526
1527         Remove support for legacy Notifications
1528         https://bugs.webkit.org/show_bug.cgi?id=171487
1529
1530         Reviewed by Jon Lee.
1531
1532         * Configurations/FeatureDefines.xcconfig:
1533         Remove definition of ENABLE_LEGACY_NOTIFICATIONS.
1534
1535 2017-05-04  Konstantin Tokarev  <annulen@yandex.ru>
1536
1537         Fix compilation with ICU 59.1
1538         https://bugs.webkit.org/show_bug.cgi?id=171612
1539
1540         Reviewed by Mark Lam.
1541
1542         ICU 59.1 has broken source compatibility. Now it defines UChar as
1543         char16_t, which does not allow automatic type conversion from unsigned
1544         short in C++ code.
1545
1546         * API/JSStringRef.cpp:
1547         (JSStringCreateWithCharacters):
1548         (JSStringCreateWithCharactersNoCopy):
1549         (JSStringGetCharactersPtr):
1550         * runtime/DateConversion.cpp:
1551         (JSC::formatDateTime):
1552
1553 2017-05-04  Saam Barati  <sbarati@apple.com>
1554
1555         stress/call-apply-exponential-bytecode-size.js.no-llint failing on 32-bit debug for OOM on executable memory
1556         https://bugs.webkit.org/show_bug.cgi?id=171008
1557
1558         Reviewed by Yusuke Suzuki.
1559
1560         This patch lowers the threshold for .call/.apply recursion
1561         in an attempt to emit less code and not impact perf.
1562         We're currently failing tests on x86-32 by running out
1563         of executable memory. If perf gets impacted because of this,
1564         then I'll apply a stricter change just to 32-bit platforms.
1565         However, if this doesn't negatively impact perf, it's all around
1566         better than all platforms emit less bytecode.
1567
1568         * bytecompiler/NodesCodegen.cpp:
1569
1570 2017-05-04  Yusuke Suzuki  <utatane.tea@gmail.com>
1571
1572         [JSC] Math unary functions should be handled by DFG
1573         https://bugs.webkit.org/show_bug.cgi?id=171269
1574
1575         Reviewed by Saam Barati.
1576
1577         ArithSin, ArithCos, and ArithLog are just calling a C runtime function.
1578         While handling them in DFG is not very effective for performance, they
1579         can drop some type checks & value conversions and mark them as pure
1580         operations. It is effective if they are involved in some complex
1581         optimization phase. Actually, ArithLog is effective in kraken.
1582
1583         While a few of Math functions have DFG nodes, basically math functions
1584         are pure. And large part of these functions are just calling a C runtime
1585         function. This patch generalizes these nodes in DFG as ArithUnary. And
1586         we annotate many unary math functions with Intrinsics and convert them
1587         to ArithUnary in DFG. It also cleans up duplicate code in ArithSin,
1588         ArithCos, and ArithLog. If your math function has some good DFG / FTL
1589         optimization rather than calling a C runtime function, you should add
1590         a specialized DFG node, like ArithSqrt.
1591
1592         We also create a new namespace JSC::Math. Inside it, we collect math functions.
1593
1594         * dfg/DFGAbstractInterpreterInlines.h:
1595         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1596         * dfg/DFGArithMode.cpp:
1597         (JSC::DFG::arithUnaryFunction):
1598         (JSC::DFG::arithUnaryOperation):
1599         (WTF::printInternal):
1600         * dfg/DFGArithMode.h:
1601         * dfg/DFGBackwardsPropagationPhase.cpp:
1602         (JSC::DFG::BackwardsPropagationPhase::propagate):
1603         * dfg/DFGByteCodeParser.cpp:
1604         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
1605         * dfg/DFGClobberize.h:
1606         (JSC::DFG::clobberize):
1607         * dfg/DFGDoesGC.cpp:
1608         (JSC::DFG::doesGC):
1609         * dfg/DFGFixupPhase.cpp:
1610         (JSC::DFG::FixupPhase::fixupNode):
1611         * dfg/DFGGraph.cpp:
1612         (JSC::DFG::Graph::dump):
1613         * dfg/DFGNode.h:
1614         (JSC::DFG::Node::hasArithUnaryType):
1615         (JSC::DFG::Node::arithUnaryType):
1616         * dfg/DFGNodeType.h:
1617         * dfg/DFGOperations.cpp:
1618         * dfg/DFGOperations.h:
1619         * dfg/DFGPredictionPropagationPhase.cpp:
1620         * dfg/DFGSafeToExecute.h:
1621         (JSC::DFG::safeToExecute):
1622         * dfg/DFGSpeculativeJIT.cpp:
1623         (JSC::DFG::SpeculativeJIT::compileArithUnary):
1624         (JSC::DFG::SpeculativeJIT::compileArithCos): Deleted.
1625         (JSC::DFG::SpeculativeJIT::compileArithTan): Deleted.
1626         (JSC::DFG::SpeculativeJIT::compileArithSin): Deleted.
1627         (JSC::DFG::SpeculativeJIT::compileArithLog): Deleted.
1628         * dfg/DFGSpeculativeJIT.h:
1629         * dfg/DFGSpeculativeJIT32_64.cpp:
1630         (JSC::DFG::SpeculativeJIT::compile):
1631         * dfg/DFGSpeculativeJIT64.cpp:
1632         (JSC::DFG::SpeculativeJIT::compile):
1633         * ftl/FTLCapabilities.cpp:
1634         (JSC::FTL::canCompile):
1635         * ftl/FTLLowerDFGToB3.cpp:
1636         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1637         (JSC::FTL::DFG::LowerDFGToB3::compileArithUnary):
1638         (JSC::FTL::DFG::LowerDFGToB3::compileArithSin): Deleted.
1639         (JSC::FTL::DFG::LowerDFGToB3::compileArithCos): Deleted.
1640         (JSC::FTL::DFG::LowerDFGToB3::compileArithTan): Deleted.
1641         (JSC::FTL::DFG::LowerDFGToB3::compileArithLog): Deleted.
1642         * ftl/FTLOutput.cpp:
1643         (JSC::FTL::Output::doubleUnary):
1644         (JSC::FTL::Output::doubleSin): Deleted.
1645         (JSC::FTL::Output::doubleCos): Deleted.
1646         (JSC::FTL::Output::doubleTan): Deleted.
1647         (JSC::FTL::Output::doubleLog): Deleted.
1648         * ftl/FTLOutput.h:
1649         * runtime/Intrinsic.h:
1650         * runtime/MathCommon.cpp:
1651         (JSC::Math::log1p):
1652         * runtime/MathCommon.h:
1653         * runtime/MathObject.cpp:
1654         (JSC::MathObject::finishCreation):
1655         (JSC::mathProtoFuncACos):
1656         (JSC::mathProtoFuncASin):
1657         (JSC::mathProtoFuncATan):
1658         (JSC::mathProtoFuncCos):
1659         (JSC::mathProtoFuncExp):
1660         (JSC::mathProtoFuncLog):
1661         (JSC::mathProtoFuncSin):
1662         (JSC::mathProtoFuncTan):
1663         (JSC::mathProtoFuncACosh):
1664         (JSC::mathProtoFuncASinh):
1665         (JSC::mathProtoFuncATanh):
1666         (JSC::mathProtoFuncCbrt):
1667         (JSC::mathProtoFuncCosh):
1668         (JSC::mathProtoFuncExpm1):
1669         (JSC::mathProtoFuncLog1p):
1670         (JSC::mathProtoFuncLog10):
1671         (JSC::mathProtoFuncLog2):
1672         (JSC::mathProtoFuncSinh):
1673         (JSC::mathProtoFuncTanh):
1674
1675 2017-05-03  Saam Barati  <sbarati@apple.com>
1676
1677         How we build polymorphic cases is wrong when making a call from Wasm
1678         https://bugs.webkit.org/show_bug.cgi?id=171527
1679
1680         Reviewed by JF Bastien.
1681
1682         This patches fixes a bug when we emit a polymorphic call IC from
1683         Wasm. We were incorrectly assuming that if we made a call *from wasm*,
1684         then the thing we are *calling to* does not have a CodeBlock. This
1685         is obviously wrong. This patch fixes the incorrect assumption.
1686         
1687         This patch also does two more things:
1688         1. Add a new option that makes us make calls to JS using a
1689         slow path instead of using a call IC.
1690         2. Fixes a potential GC bug where we didn't populate JSWebAssemblyCodeBlock's
1691         JSWebAssemblyModule pointer.
1692
1693         * jit/Repatch.cpp:
1694         (JSC::linkPolymorphicCall):
1695         * runtime/Options.h:
1696         * wasm/WasmBinding.cpp:
1697         (JSC::Wasm::wasmToJs):
1698         * wasm/js/JSWebAssemblyCodeBlock.cpp:
1699         (JSC::JSWebAssemblyCodeBlock::create):
1700         (JSC::JSWebAssemblyCodeBlock::finishCreation):
1701         * wasm/js/JSWebAssemblyCodeBlock.h:
1702         * wasm/js/JSWebAssemblyInstance.cpp:
1703         (JSC::JSWebAssemblyInstance::finalizeCreation):
1704
1705 2017-05-03  Keith Miller  <keith_miller@apple.com>
1706
1707         Array.prototype.sort should also allow a null comparator
1708         https://bugs.webkit.org/show_bug.cgi?id=171621
1709         <rdar://problem/30757933>
1710
1711         Reviewed by Michael Saboff.
1712
1713         It looks like sort not accepting a null comparator
1714         causes some pages to stop working. Those pages work in
1715         Chrome/Firefox so we should try to match them.
1716
1717         * builtins/ArrayPrototype.js:
1718         (sort):
1719
1720 2017-05-03  Mark Lam  <mark.lam@apple.com>
1721
1722         Use the CLoop for CPU(ARM64E).
1723         https://bugs.webkit.org/show_bug.cgi?id=171620
1724         <rdar://problem/31973027>
1725
1726         Reviewed by Geoffrey Garen.
1727
1728         * llint/LLIntOfflineAsmConfig.h:
1729         * tools/SigillCrashAnalyzer.cpp:
1730         (JSC::SigillCrashAnalyzer::dumpCodeBlock):
1731
1732 2017-05-03  Keith Miller  <keith_miller@apple.com>
1733
1734         Different behaviour with the .sort(callback) method (unlike Firefox & Chrome)
1735         https://bugs.webkit.org/show_bug.cgi?id=47825
1736
1737         Reviewed by Saam Barati.
1738
1739         This patch makes our sort function match the behavior of Firefox
1740         and Chrome when the result of the comparison function is a
1741         boolean. When we first switched to using merge sort, it regressed
1742         JQuery sorting of DOM nodes by 30%. The regression was do to the
1743         fact that JQuery was using compareDocumentPosition to compare the
1744         locations of objects. Since one of the benchmarks would pass a
1745         reverse sorted list to the sort function we would end up walking
1746         the entire DOM to do comparisons. The solution to this was to
1747         merge based on comparison(right, left) rather than
1748         comparison(left, right). Although, in practice this does nothing
1749         since sort could just as easily receive an already sorted list and
1750         we're back in the same spot.
1751
1752         The downside of sorting with comparison(right, left) is that to
1753         maintain stability when sorting, you only want to merge from right
1754         when the comparison function returns a negative value. This is
1755         where the problem with booleans comes in. Since booleans toNumber
1756         false to 0 and true to 1 both values are "equal". This patch fixes
1757         this by special casing boolean return values.
1758
1759
1760         * builtins/ArrayPrototype.js:
1761         (sort.merge):
1762
1763 2017-05-03  Andy VanWagoner  <thetalecrafter@gmail.com>
1764
1765         [INTL] Support dashed values in unicode locale extensions
1766         https://bugs.webkit.org/show_bug.cgi?id=171480
1767
1768         Reviewed by JF Bastien.
1769
1770         Implements the UnicodeExtensionSubtags operation and updates the ResolveLocale operation to use it.
1771         This fixes locale extensions with values that include '-'. The following calendars work now:
1772         ethiopic-amete-alem
1773         islamic-umalqura
1774         islamic-tbla
1775         islamic-civil
1776         islamic-rgsa
1777
1778         While updating IntlObject, the comments containing spec text were replaced with a single url at the
1779         top of each function pointing to the relevant part of ECMA-402.
1780
1781         * runtime/IntlObject.cpp:
1782         (JSC::unicodeExtensionSubTags): Added.
1783         (JSC::resolveLocale): Updated to latest standard.
1784
1785 2017-05-02  Don Olmstead  <don.olmstead@am.sony.com>
1786
1787         Build fix after r216078
1788         https://bugs.webkit.org/show_bug.cgi?id=171554
1789
1790         Reviewed by Saam Barati.
1791
1792         * API/tests/testapi.c:
1793
1794 2017-05-02  Filip Pizlo  <fpizlo@apple.com>
1795
1796         Unreviewed, fix pedantic C compilers.
1797
1798         * API/tests/testapi.c:
1799         (markingConstraint):
1800         (testMarkingConstraints):
1801
1802 2017-05-02  Filip Pizlo  <fpizlo@apple.com>
1803
1804         Unreviewed, fix cmake build.
1805
1806         * CMakeLists.txt:
1807
1808 2017-05-02  Filip Pizlo  <fpizlo@apple.com>
1809
1810         JSC C API should expose GC marking constraints and weak references
1811         https://bugs.webkit.org/show_bug.cgi?id=171554
1812
1813         Reviewed by Geoffrey Garen.
1814         
1815         This exposes an API that lets you participate in the GC's fixpoint. You can ask the GC
1816         what is marked and you can tell the GC to mark things. The constraint callback cannot
1817         do a whole lot, but it can query marking state and it can dereference weak references.
1818         
1819         Additionally, this exposes a very simple weak reference API in C.
1820
1821         * API/JSMarkingConstraintPrivate.cpp: Added.
1822         (JSC::isMarked):
1823         (JSC::mark):
1824         (JSContextGroupRegisterMarkingConstraint):
1825         * API/JSMarkingConstraintPrivate.h: Added.
1826         * API/JSWeakPrivate.cpp: Added.
1827         (OpaqueJSWeak::OpaqueJSWeak):
1828         (JSWeakCreate):
1829         (JSWeakRetain):
1830         (JSWeakRelease):
1831         (JSWeakGetObject):
1832         * API/JSWeakPrivate.h: Added.
1833         * API/tests/testapi.c:
1834         (markingConstraint):
1835         (testMarkingConstraints):
1836         (main):
1837         * JavaScriptCore.xcodeproj/project.pbxproj:
1838         * heap/SlotVisitor.h:
1839         * heap/SlotVisitorInlines.h:
1840         (JSC::SlotVisitor::appendHiddenUnbarriered):
1841         (JSC::SlotVisitor::appendHidden):
1842
1843 2017-05-02  Mark Lam  <mark.lam@apple.com>
1844
1845         JSFixedArray::allocationSize() should not allow for allocation failure.
1846         https://bugs.webkit.org/show_bug.cgi?id=171516
1847
1848         Reviewed by Geoffrey Garen.
1849
1850         Since JSFixedArray::createFromArray() now handles allocation failures by throwing
1851         OutOfMemoryErrors, its helper function allocationSize() (which computes the buffer
1852         size to allocate) should also allow for allocation failure on overflow.
1853
1854         This issue is covered by the stress/js-fixed-array-out-of-memory.js test when
1855         run on 32-bit builds.
1856
1857         * runtime/JSFixedArray.h:
1858         (JSC::JSFixedArray::tryCreate):
1859         (JSC::JSFixedArray::allocationSize):
1860
1861 2017-05-01  Zan Dobersek  <zdobersek@igalia.com>
1862
1863         [aarch64][Linux] m_allowScratchRegister assert hit in MacroAssemblerARM64 under B3::Air::CCallSpecial::generate()
1864         https://bugs.webkit.org/show_bug.cgi?id=170672
1865
1866         Reviewed by Filip Pizlo.
1867
1868         In Air::CCallSpecial::admitsStack() we reject admitting the callee argument on
1869         the stack for ARM64 because that can lead to disallowed usage of the scratch
1870         register in MacroAssemblerARM64 when generating a call with an address Arg
1871         in Air::CCallSpecial::generate().
1872
1873         The testLinearScanWithCalleeOnStack test is added to testb3. It reproduces the
1874         original issue by force-spilling everything on the stack and enforcing the use
1875         of the linear scan register allocation by using an optimization level of 1.
1876
1877         * b3/air/AirCCallSpecial.cpp:
1878         (JSC::B3::Air::CCallSpecial::admitsStack):
1879         * b3/testb3.cpp:
1880         (JSC::B3::testLinearScanWithCalleeOnStack):
1881         (JSC::B3::run):
1882
1883 2017-05-01  David Kilzer  <ddkilzer@apple.com>
1884
1885         Stop using sprintf() in JavaScriptCore debugger
1886         <https://webkit.org/b/171512>
1887
1888         Reviewed by Keith Miller.
1889
1890         * disassembler/udis86/udis86.c:
1891         (ud_insn_hex): Switch from sprintf() to snprintf().
1892
1893 2017-04-21  Filip Pizlo  <fpizlo@apple.com>
1894
1895         Air::fixObviousSpills should remove totally redundant instructions
1896         https://bugs.webkit.org/show_bug.cgi?id=171131
1897
1898         Reviewed by Saam Barati.
1899         
1900         This is a modest compile-time-neutral improvement to fixObviousSpills. That phase
1901         builds up a classic alias analysis data structure over spills and registers and then
1902         uses it to remove the most common spill pathologies we encounter. For example, if you
1903         use a spill but the spill is aliased to a register or constant, then we can replace the
1904         use of the spill with a use of the register or constant.
1905         
1906         But that phase was missing perhaps one of the most obvious fixups that its analysis
1907         allows us to do: if any instruction creates an alias we already know about, then the
1908         instruction is redundant. This turned out to be super important for
1909         https://bugs.webkit.org/show_bug.cgi?id=171075. That patch didn't work out, but this
1910         kind of optimization might be a good clean-up for many other kinds of optimizations.
1911
1912         * b3/air/AirFixObviousSpills.cpp:
1913
1914 2017-04-30  Oleksandr Skachkov  <gskachkov@gmail.com>
1915
1916         We initialize functions too early in an eval
1917         https://bugs.webkit.org/show_bug.cgi?id=161099
1918
1919         Reviewed by Saam Barati.
1920
1921         Current patch allow to fix problem with scope in function that is 
1922         declared within eval. Before scope was set inside Interpretator.cpp and it
1923         was scope where eval is executed, but in this case function would not 
1924         see let/const variables and classes declated in eval.
1925         This patch devide declaration and binding in two operation, first just declare
1926         variable with function name, and second bind variable to function with correct 
1927         scope
1928
1929         * bytecompiler/BytecodeGenerator.cpp:
1930         (JSC::BytecodeGenerator::generate):
1931         (JSC::BytecodeGenerator::BytecodeGenerator):
1932         * bytecompiler/BytecodeGenerator.h:
1933         * interpreter/Interpreter.cpp:
1934         (JSC::Interpreter::execute):
1935
1936 2017-04-30  Oleksandr Skachkov  <gskachkov@gmail.com>
1937
1938         [ES6]. Implement Annex B.3.3 function hoisting rules for eval
1939         https://bugs.webkit.org/show_bug.cgi?id=163208
1940
1941         Reviewed by Saam Barati.
1942
1943         Current patch implements Annex B.3.3 that is related to 
1944         hoisting of function declaration in eval. 
1945         https://tc39.github.io/ecma262/#sec-web-compat-evaldeclarationinstantiation
1946         Function declaration in eval should create variable with 
1947         function name in function scope where eval is invoked 
1948         or bind to variable if it declared outside of the eval. 
1949         If variable is created it can be removed by 'delete a;' command. 
1950         If eval is invoke in block scope that contains let/const 
1951         variable with the same name as function declaration 
1952         we do not bind. This patch leads to the following behavior: 
1953         '''
1954         function foo() {
1955            {
1956              print(boo); // undefined
1957              eval('{ function boo() {}}');
1958              print(boo); // function boo() {}
1959            }
1960            print(boo); // function boo() {}
1961         }
1962
1963         function foobar() {
1964           { 
1965             let boo = 10;
1966             print(boo); // 10;
1967             eval('{ function boo() {}}');
1968             print(boo); // 10;
1969           }
1970           print(boo) // 10
1971         }
1972
1973         function bar() {
1974            {
1975               var boo = 10;
1976               print(boo); // 10
1977               eval('{ function boo() {} }'); 
1978               print(boo); // function boo() {}
1979            }
1980            print(boo); // function boo() {}
1981         }       
1982         
1983         function bas() {
1984             {
1985                  let boo = 10;
1986                  eval(' { function boo() {} } ');
1987                  print(boo); // 10
1988             }
1989             print(boo); //Reference Error
1990         }
1991         '''
1992
1993         Current implementation relies on already implemented 
1994         'hoist function in sloppy mode' feature, with small changes.
1995         In short it works in following way: during hoisting of function 
1996         with name S in eval, we are looking for first scope that 
1997         contains space for variable with name S and if this scope 
1998         has var type we bind function there
1999
2000         To implement this feature was added bytecode ops:
2001         op_resolve_scope_for_hoisting_func_decl_in_eval - get variable scope 
2002         or return undefined if variable can't be binded there.
2003
2004         There is a corner case, hoist function in eval within catch block,
2005         that is not covered by this patch, and will be fixed in 
2006         https://bugs.webkit.org/show_bug.cgi?id=168184
2007
2008         * bytecode/BytecodeDumper.cpp:
2009         (JSC::BytecodeDumper<Block>::dumpBytecode):
2010         * bytecode/BytecodeList.json:
2011         * bytecode/BytecodeUseDef.h:
2012         (JSC::computeUsesForBytecodeOffset):
2013         (JSC::computeDefsForBytecodeOffset):
2014         * bytecode/CodeBlock.cpp:
2015         (JSC::CodeBlock::finalizeLLIntInlineCaches):
2016         * bytecode/EvalCodeBlock.h:
2017         (JSC::EvalCodeBlock::functionHoistingCandidate):
2018         (JSC::EvalCodeBlock::numFunctionHoistingCandidates):
2019         * bytecode/UnlinkedEvalCodeBlock.h:
2020         * bytecompiler/BytecodeGenerator.cpp:
2021         (JSC::BytecodeGenerator::BytecodeGenerator):
2022         (JSC::BytecodeGenerator::hoistSloppyModeFunctionIfNecessary):
2023         (JSC::BytecodeGenerator::emitResolveScopeForHoistingFuncDeclInEval):
2024         * bytecompiler/BytecodeGenerator.h:
2025         * dfg/DFGAbstractInterpreterInlines.h:
2026         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2027         * dfg/DFGByteCodeParser.cpp:
2028         (JSC::DFG::ByteCodeParser::parseBlock):
2029         * dfg/DFGCapabilities.cpp:
2030         (JSC::DFG::capabilityLevel):
2031         * dfg/DFGClobberize.h:
2032         (JSC::DFG::clobberize):
2033         * dfg/DFGDoesGC.cpp:
2034         (JSC::DFG::doesGC):
2035         * dfg/DFGFixupPhase.cpp:
2036         (JSC::DFG::FixupPhase::fixupNode):
2037         * dfg/DFGNode.h:
2038         (JSC::DFG::Node::hasIdentifier):
2039         * dfg/DFGNodeType.h:
2040         * dfg/DFGOperations.cpp:
2041         * dfg/DFGOperations.h:
2042         * dfg/DFGPredictionPropagationPhase.cpp:
2043         * dfg/DFGSafeToExecute.h:
2044         (JSC::DFG::safeToExecute):
2045         * dfg/DFGSpeculativeJIT.cpp:
2046         (JSC::DFG::SpeculativeJIT::compileResolveScopeForHoistingFuncDeclInEval):
2047         * dfg/DFGSpeculativeJIT.h:
2048         (JSC::DFG::SpeculativeJIT::callOperation):
2049         * dfg/DFGSpeculativeJIT32_64.cpp:
2050         (JSC::DFG::SpeculativeJIT::compile):
2051         * dfg/DFGSpeculativeJIT64.cpp:
2052         (JSC::DFG::SpeculativeJIT::compile):
2053         * ftl/FTLCapabilities.cpp:
2054         (JSC::FTL::canCompile):
2055         * ftl/FTLLowerDFGToB3.cpp:
2056         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2057         (JSC::FTL::DFG::LowerDFGToB3::compileResolveScopeForHoistingFuncDeclInEval):
2058         * interpreter/Interpreter.cpp:
2059         (JSC::Interpreter::execute):
2060         * jit/JIT.cpp:
2061         (JSC::JIT::privateCompileMainPass):
2062         * jit/JIT.h:
2063         * jit/JITOperations.h:
2064         * jit/JITPropertyAccess.cpp:
2065         (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval):
2066         * jit/JITPropertyAccess32_64.cpp:
2067         (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval):
2068         * llint/LowLevelInterpreter.asm:
2069         * parser/Parser.cpp:
2070         (JSC::Parser<LexerType>::parseFunctionDeclarationStatement):
2071         * parser/Parser.h:
2072         (JSC::Scope::getSloppyModeHoistedFunctions):
2073         (JSC::Parser::declareFunction):
2074         * runtime/CommonSlowPaths.cpp:
2075         (JSC::SLOW_PATH_DECL):
2076         * runtime/CommonSlowPaths.h:
2077         * runtime/EvalExecutable.h:
2078         (JSC::EvalExecutable::numFunctionHoistingCandidates):
2079         (JSC::EvalExecutable::numTopLevelFunctionDecls):
2080         (JSC::EvalExecutable::numberOfFunctionDecls): Deleted.
2081         * runtime/JSScope.cpp:
2082         (JSC::JSScope::resolve):
2083         (JSC::JSScope::resolveScopeForHoistingFuncDeclInEval):
2084         * runtime/JSScope.h:
2085
2086 2017-04-29  Oleksandr Skachkov  <gskachkov@gmail.com>
2087
2088         Deep nesting is leading to ReferenceError for hoisted function
2089         https://bugs.webkit.org/show_bug.cgi?id=171456
2090
2091         Reviewed by Yusuke Suzuki.
2092
2093         Current patch fix error that appears during hoisting of the function 
2094         in block scope. Error happens only when exist some deep scope that lead
2095         to increase scope stack, after which list of the hosted candidates do not 
2096         copied to updated scope stack.
2097
2098         * parser/Parser.h:
2099         (JSC::Scope::Scope):
2100
2101 2017-04-29  Yusuke Suzuki  <utatane.tea@gmail.com>
2102
2103         [JSC] LabelScopePtr is not necessary
2104         https://bugs.webkit.org/show_bug.cgi?id=171474
2105
2106         Reviewed by Geoffrey Garen.
2107
2108         Originally, LabelScopePtr is introduced because LabelScopes uses Vector<> instead of SegmentedVector<>.
2109         LabelScopePtr holds the pointer to the vector owner and index instead of the pointer to LabelScope directly
2110         since Vector<> can relocate LocalScopes inside it.
2111         The reason why LabelScopes use Vector instead is that there is code copying this vector. SegmentedVector<>
2112         prohibits copying since it is so costly. So, we used Vector<> here instead of SegmentedVector<>.
2113
2114         But the latest code does not have copying code for LabelScopes. Thus, we can take the same design to Label and
2115         RegisterID. Just use SegmentedVector<> and Ref<>/RefPtr<>. This patch removes LabelScopePtr since it is no
2116         longer necessary. And use SegmentedVector for LabelScopes.
2117
2118         * bytecompiler/BytecodeGenerator.cpp:
2119         (JSC::reclaim):
2120         (JSC::BytecodeGenerator::reclaimFreeRegisters):
2121         (JSC::BytecodeGenerator::newLabelScope):
2122         (JSC::BytecodeGenerator::newLabel):
2123         (JSC::BytecodeGenerator::pushFinallyControlFlowScope):
2124         (JSC::BytecodeGenerator::breakTarget):
2125         (JSC::BytecodeGenerator::continueTarget):
2126         (JSC::BytecodeGenerator::emitEnumeration):
2127         * bytecompiler/BytecodeGenerator.h:
2128         * bytecompiler/LabelScope.h:
2129         (JSC::LabelScope::LabelScope):
2130         (JSC::LabelScope::breakTarget):
2131         (JSC::LabelScope::continueTarget):
2132         (JSC::LabelScope::type):
2133         (JSC::LabelScope::name):
2134         (JSC::LabelScope::scopeDepth):
2135         (JSC::LabelScope::ref):
2136         (JSC::LabelScope::deref):
2137         (JSC::LabelScope::refCount):
2138         (JSC::LabelScopePtr::LabelScopePtr): Deleted.
2139         (JSC::LabelScopePtr::operator=): Deleted.
2140         (JSC::LabelScopePtr::~LabelScopePtr): Deleted.
2141         (JSC::LabelScopePtr::operator!): Deleted.
2142         (JSC::LabelScopePtr::operator*): Deleted.
2143         (JSC::LabelScopePtr::operator->): Deleted.
2144         (JSC::LabelScopePtr::null): Deleted.
2145         * bytecompiler/NodesCodegen.cpp:
2146         (JSC::DoWhileNode::emitBytecode):
2147         (JSC::WhileNode::emitBytecode):
2148         (JSC::ForNode::emitBytecode):
2149         (JSC::ForInNode::emitBytecode):
2150         (JSC::ContinueNode::trivialTarget):
2151         (JSC::ContinueNode::emitBytecode):
2152         (JSC::BreakNode::trivialTarget):
2153         (JSC::BreakNode::emitBytecode):
2154         (JSC::SwitchNode::emitBytecode):
2155         (JSC::LabelNode::emitBytecode):
2156
2157 2017-04-28  Mark Lam  <mark.lam@apple.com>
2158
2159         Revert instrumentation from https://bugs.webkit.org/show_bug.cgi?id=170086 that is no longer needed.
2160         https://bugs.webkit.org/show_bug.cgi?id=170094
2161
2162         Reviewed by JF Bastien and Keith Miller.
2163
2164         * heap/Heap.cpp:
2165         (JSC::Heap::resumeThePeriphery):
2166
2167 2017-04-27  Andy VanWagoner  <thetalecrafter@gmail.com>
2168
2169         [INTL] Implement the caseFirst option for Intl.Collator
2170         https://bugs.webkit.org/show_bug.cgi?id=158188
2171
2172         Reviewed by Geoffrey Garen.
2173
2174         Implements the caseFirst option and unicode locale extension.
2175         The caseFirst option explicitly determines whether upper or lower case comes first.
2176
2177         * runtime/IntlCollator.cpp:
2178         (JSC::sortLocaleData): Added kf data.
2179         (JSC::searchLocaleData): Added kf data.
2180         (JSC::IntlCollator::initializeCollator): Set caseFirst option.
2181         (JSC::IntlCollator::createCollator): Set new attributes on ICU collator.
2182         (JSC::IntlCollator::caseFirstString): Added.
2183         (JSC::IntlCollator::resolvedOptions): Added caseFirst property.
2184         * runtime/IntlCollator.h:
2185
2186 2017-04-27  Mark Lam  <mark.lam@apple.com>
2187
2188         Fix some RELEASE_ASSERT failures caused by OutOfMemoryErrors.
2189         https://bugs.webkit.org/show_bug.cgi?id=171404
2190         <rdar://problem/31876178>
2191
2192         Reviewed by Saam Barati.
2193
2194         1. Added some tryAllocate() functions in JSCellInlines.h.
2195         2. Consolidated the implementations of allocateCell() template functions into a
2196            single tryAllocateCellHelper() to reduce redundancy and eliminate needing to
2197            copy-paste for variations of allocateCell and tryAllocateCell.
2198         3. Changed JSFixedArray::createFromArray() and constructEmptyArray() to check for
2199            allocation failure and throw an OutOfMemoryError.  It was already possible to
2200            throw errors from these functions for other reasons.  So, their clients are
2201            already ready to handle OOMEs.
2202
2203         * ftl/FTLOperations.cpp:
2204         (JSC::FTL::operationMaterializeObjectInOSR):
2205         * runtime/JSCInlines.h:
2206         * runtime/JSCell.h:
2207         * runtime/JSCellInlines.h:
2208         (JSC::tryAllocateCellHelper):
2209         (JSC::allocateCell):
2210         (JSC::tryAllocateCell):
2211         * runtime/JSFixedArray.h:
2212         (JSC::JSFixedArray::createFromArray):
2213         (JSC::JSFixedArray::tryCreate):
2214         (JSC::JSFixedArray::create): Deleted.
2215         * runtime/JSGlobalObject.h:
2216         (JSC::constructEmptyArray):
2217
2218 2017-04-27  Joseph Pecoraro  <pecoraro@apple.com>
2219
2220         Support for promise rejection events (unhandledrejection)
2221         https://bugs.webkit.org/show_bug.cgi?id=150358
2222         <rdar://problem/28441651>
2223
2224         Reviewed by Saam Barati.
2225
2226         Patch by Joseph Pecoraro and Yusuke Suzuki.
2227
2228         Implement support for promise.[[PromiseIsHandled]] and the
2229         HostPromiseRejectionTracker hook for HTML to track promise rejections:
2230         https://tc39.github.io/ecma262/#sec-host-promise-rejection-tracker
2231         https://html.spec.whatwg.org/multipage/webappapis.html#unhandled-promise-rejections
2232
2233         * builtins/BuiltinNames.h:
2234         New private symbols.
2235
2236         * builtins/PromiseOperations.js:
2237         (globalPrivate.newHandledRejectedPromise):
2238         Utility to create a rejected promise with [[PromiseIsHandled]] to true.
2239
2240         (globalPrivate.rejectPromise):
2241         (globalPrivate.initializePromise):
2242         * builtins/PromisePrototype.js:
2243         (then):
2244         Implement standard behavior of [[PromiseIsHandled]] and the host hook.
2245
2246         * runtime/JSPromise.cpp:
2247         (JSC::JSPromise::isHandled):
2248         * runtime/JSPromise.h:
2249         C++ accessors for the [[PromiseIsHandled]] state.
2250
2251         * bytecode/BytecodeIntrinsicRegistry.cpp:
2252         (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
2253         * bytecode/BytecodeIntrinsicRegistry.h:
2254         Expose private values for the Reject / Handle enum values in built-ins.
2255
2256         * jsc.cpp:
2257         * runtime/JSGlobalObject.h:
2258         (JSC::JSGlobalObject::promiseResolveFunction):
2259         Add a new GlobalObjectMethodTable hook matching the promise rejection hook.
2260
2261         * runtime/JSGlobalObject.cpp:
2262         (JSC::JSGlobalObject::init):
2263         (JSC::JSGlobalObject::visitChildren):
2264         * runtime/JSGlobalObjectFunctions.cpp:
2265         (JSC::globalFuncHostPromiseRejectionTracker):
2266         * runtime/JSGlobalObjectFunctions.h:
2267         Plumb the builtin hook through to the optional GlobalObjectMethodTable hook.
2268
2269         * inspector/InjectedScriptSource.js:
2270         (InjectedScript.prototype.createFakeValueDescriptor):
2271         Silence possible rejected promises created internally via Web Inspector.
2272
2273 2017-04-27  Saam Barati  <sbarati@apple.com>
2274
2275         B3::FoldPathConstants does not consider the fall through case for Switch
2276         https://bugs.webkit.org/show_bug.cgi?id=171390
2277
2278         Reviewed by Filip Pizlo.
2279
2280         foldPathConstants was not taking into account a Switch's default
2281         case when it tried to constant propagate the switch's operand value.
2282         e.g, we incorrectly transformed this code:
2283         
2284         ```
2285         x = argumentGPR0;
2286         switch (x) {
2287         case 10: return 20;
2288         
2289         case 0:
2290         default: return x == 0;
2291         }
2292         ```
2293         
2294         into:
2295         ```
2296         x = argumentGPR0;
2297         switch (x) {
2298         case 10: return 20;
2299         
2300         case 0:
2301         default: return 1;
2302         }
2303         ```
2304         
2305         Because we didn't take into account the default case, we incorrectly
2306         optimized the code as if case 0's block was only reachable if x is
2307         equal to zero. This is obviously not true, since it's the same block
2308         as the default case.
2309         
2310         This fix ensures that we can run the WebAssembly Tanks demo even when
2311         we set webAssemblyBBQOptimizationLevel=2.
2312
2313         * b3/B3FoldPathConstants.cpp:
2314         * b3/B3SwitchValue.cpp:
2315         (JSC::B3::SwitchValue::fallThrough):
2316         (JSC::B3::SwitchValue::removeCase): Deleted.
2317         * b3/B3SwitchValue.h:
2318         * b3/testb3.cpp:
2319         (JSC::B3::testCallFunctionWithHellaArguments):
2320         (JSC::B3::testSwitchSameCaseAsDefault):
2321         (JSC::B3::testWasmBoundsCheck):
2322         (JSC::B3::run):
2323
2324 2017-04-27  Keith Miller  <keith_miller@apple.com>
2325
2326         WebAssembly: Don't tier up the same function twice
2327         https://bugs.webkit.org/show_bug.cgi?id=171397
2328
2329         Reviewed by Filip Pizlo.
2330
2331         Because we don't CAS the tier up count on function entry/loop backedge and we use the least significant to indicate whether or not tier up has already started we could see the following:
2332
2333         Threads A and B are running count in memory is (0):
2334
2335         A: load tier up count (0)
2336         B: load tier up count (0)
2337         A: decrement count to -2 and see we need to check for tier up (0)
2338         A: store -2 to count (-2)
2339         A: exchangeOr(1) to tier up count (-1)
2340         B: decrement count to -2 and see we need to check for tier up (-1)
2341         B: store -2 to count (-2)
2342         B: exchangeOr(1) to tier up count (-1)
2343
2344         This would cause us to tier up the same function twice, which we would rather avoid.
2345
2346         * wasm/WasmB3IRGenerator.cpp:
2347         (JSC::Wasm::B3IRGenerator::emitTierUpCheck):
2348         * wasm/WasmTierUpCount.h:
2349         (JSC::Wasm::TierUpCount::TierUpCount):
2350         (JSC::Wasm::TierUpCount::loopDecrement):
2351         (JSC::Wasm::TierUpCount::functionEntryDecrement):
2352         (JSC::Wasm::TierUpCount::shouldStartTierUp):
2353
2354 2017-04-27  Keith Miller  <keith_miller@apple.com>
2355
2356         REGRESSION (r215843): ASSERTION FAILED: !m_completionTasks[0].first in  JSC::Wasm::Plan::tryRemoveVMAndCancelIfLast(JSC::VM &)
2357         https://bugs.webkit.org/show_bug.cgi?id=171380
2358
2359         Reviewed by JF Bastien.
2360
2361         This patch fixes the association of VMs to Wasm::Plans. For validation
2362         we want all the completion tasks to be associate with a VM. For BBQ,
2363         we want the main task to not be associated with any VM.
2364
2365         * jsc.cpp:
2366         (functionTestWasmModuleFunctions):
2367         * wasm/WasmBBQPlan.cpp:
2368         (JSC::Wasm::BBQPlan::BBQPlan):
2369         * wasm/WasmBBQPlan.h:
2370         * wasm/WasmCodeBlock.cpp:
2371         (JSC::Wasm::CodeBlock::CodeBlock):
2372         (JSC::Wasm::CodeBlock::compileAsync):
2373         * wasm/WasmCodeBlock.h:
2374         (JSC::Wasm::CodeBlock::create):
2375         * wasm/WasmModule.cpp:
2376         (JSC::Wasm::makeValidationCallback):
2377         (JSC::Wasm::Module::validateSync):
2378         (JSC::Wasm::Module::validateAsync):
2379         (JSC::Wasm::Module::getOrCreateCodeBlock):
2380         (JSC::Wasm::Module::compileSync):
2381         (JSC::Wasm::Module::compileAsync):
2382         * wasm/WasmModule.h:
2383         * wasm/WasmOMGPlan.cpp:
2384         (JSC::Wasm::OMGPlan::OMGPlan):
2385         (JSC::Wasm::runOMGPlanForIndex):
2386         * wasm/WasmOMGPlan.h:
2387         * wasm/WasmPlan.cpp:
2388         (JSC::Wasm::Plan::Plan):
2389         (JSC::Wasm::Plan::runCompletionTasks):
2390         (JSC::Wasm::Plan::addCompletionTask):
2391         (JSC::Wasm::Plan::tryRemoveVMAndCancelIfLast):
2392         * wasm/WasmPlan.h:
2393         (JSC::Wasm::Plan::dontFinalize):
2394         * wasm/js/WebAssemblyInstanceConstructor.cpp:
2395         (JSC::constructJSWebAssemblyInstance):
2396         * wasm/js/WebAssemblyPrototype.cpp:
2397         (JSC::webAssemblyValidateFunc):
2398
2399 2017-04-27  Saam Barati  <sbarati@apple.com>
2400
2401         Restore some caching functionality that got accidentally removed when doing Wasm PIC patches
2402         https://bugs.webkit.org/show_bug.cgi?id=171382
2403
2404         Reviewed by Keith Miller.
2405
2406         When I created Wasm::CodeBlock, I accidentally removed caching
2407         the creation of JSWebAssemblyCodeBlocks. This patch restores it.
2408         It's worth keeping JSWebAssemblyModule's JSWebAssemblyCodeBlock
2409         cache because creating a JSWebAssemblyCodeBlock does non trivial
2410         work by creating the various IC call stubs.
2411
2412         * wasm/js/JSWebAssemblyCodeBlock.h:
2413         (JSC::JSWebAssemblyCodeBlock::codeBlock):
2414         * wasm/js/JSWebAssemblyInstance.cpp:
2415         (JSC::JSWebAssemblyInstance::finalizeCreation):
2416         (JSC::JSWebAssemblyInstance::create):
2417         * wasm/js/JSWebAssemblyModule.h:
2418
2419 2017-04-27  Mark Lam  <mark.lam@apple.com>
2420
2421         Audit and fix incorrect uses of JSArray::tryCreateForInitializationPrivate().
2422         https://bugs.webkit.org/show_bug.cgi?id=171344
2423         <rdar://problem/31352667>
2424
2425         Reviewed by Filip Pizlo.
2426
2427         JSArray::tryCreateForInitializationPrivate() should only be used in performance
2428         critical paths, and should always be used with care because it creates an
2429         uninitialized object that needs to be initialized by its client before the object
2430         can be released into the system.  Before the object is fully initialized:
2431         a. the client should not re-enter the VM to execute JS code, and
2432         b. GC should not run.
2433
2434         This is because until the object is fully initialized, it is an inconsistent
2435         state that the GC and JS code will not be happy about.
2436
2437         In this patch, we do the following:
2438
2439         1. Renamed JSArray::tryCreateForInitializationPrivate() to
2440            JSArray::tryCreateUninitializedRestricted() because "private" is a bit ambiguous
2441            and can be confused with APIs that are called freely within WebKit but are
2442            not meant for clients of WebKit.  In this case, we intend for use of this API
2443            to be restricted to only a few carefully considered and crafted cases.
2444
2445         2. Introduce the ObjectInitializationScope RAII object which covers the period
2446            when the uninitialized object is created and gets initialized.
2447
2448            ObjectInitializationScope will asserts that either the object is created
2449            fully initialized (in the case where the object structure is not an "original"
2450            structure) or if created uninitialized, is fully initialized at the end of
2451            the scope.
2452
2453            If the object is created uninitialized, the ObjectInitializationScope also
2454            ensures that we do not GC nor re-enter the VM to execute JS code.  This is
2455            achieved by enabling DisallowGC and DisallowVMReentry scopes.
2456
2457            tryCreateUninitializedRestricted() and initializeIndex() now requires an
2458            ObjectInitializationScope instance.  The ObjectInitializationScope replaces
2459            the VM& argument because it can be used to pass the VM& itself.  This is a
2460            small optimization that makes passing the ObjectInitializationScope free even
2461            on release builds.
2462
2463         3. Factored a DisallowScope out of DisallowGC, and make DisallowGC extend it.
2464            Introduce a DisallowVMReentry class that extends DisallowScope.
2465
2466         4. Fixed a bug found by the ObjectInitializationScope.  The bug is that there are
2467            scenarios where the structure passed to tryCreateUninitializedRestricted()
2468            that may not be an "original" structure.  As a result, initializeIndex() would
2469            end up allocating new structures, and therefore trigger a GC.
2470
2471            The fix is to detect that the structure passed to tryCreateUninitializedRestricted()
2472            is not an "original" one, and pre-initialize the array with 0s.
2473
2474            This bug was detected by existing tests. Hence, no new test needed.
2475
2476         5. Replaced all inappropriate uses of tryCreateUninitializedRestricted() with
2477            tryCreate().  Inappropriate uses here means code that is not in performance
2478            critical paths.
2479
2480            Similarly, replaced accompanying uses of initializeIndex() with putDirectIndex().
2481
2482            This patch is performance neutral (according to the JSC command line benchmarks).
2483
2484         * CMakeLists.txt:
2485         * JavaScriptCore.xcodeproj/project.pbxproj:
2486         * dfg/DFGOperations.cpp:
2487         * ftl/FTLOperations.cpp:
2488         (JSC::FTL::operationMaterializeObjectInOSR):
2489         * heap/DeferGC.cpp:
2490         * heap/DeferGC.h:
2491         (JSC::DisallowGC::DisallowGC):
2492         (JSC::DisallowGC::initialize):
2493         (JSC::DisallowGC::scopeReentryCount):
2494         (JSC::DisallowGC::setScopeReentryCount):
2495         (JSC::DisallowGC::~DisallowGC): Deleted.
2496         (JSC::DisallowGC::isGCDisallowedOnCurrentThread): Deleted.
2497         * heap/GCDeferralContextInlines.h:
2498         (JSC::GCDeferralContext::~GCDeferralContext):
2499         * heap/Heap.cpp:
2500         (JSC::Heap::collectIfNecessaryOrDefer):
2501         * runtime/ArrayPrototype.cpp:
2502         (JSC::arrayProtoPrivateFuncConcatMemcpy):
2503         * runtime/ClonedArguments.cpp:
2504         (JSC::ClonedArguments::createWithInlineFrame):
2505         (JSC::ClonedArguments::createByCopyingFrom):
2506         * runtime/CommonSlowPaths.cpp:
2507         (JSC::SLOW_PATH_DECL):
2508         * runtime/DisallowScope.h: Added.
2509         (JSC::DisallowScope::DisallowScope):
2510         (JSC::DisallowScope::~DisallowScope):
2511         (JSC::DisallowScope::isInEffectOnCurrentThread):
2512         (JSC::DisallowScope::enable):
2513         (JSC::DisallowScope::enterScope):
2514         (JSC::DisallowScope::exitScope):
2515         * runtime/DisallowVMReentry.cpp: Added.
2516         * runtime/DisallowVMReentry.h: Added.
2517         (JSC::DisallowVMReentry::DisallowVMReentry):
2518         (JSC::DisallowVMReentry::initialize):
2519         (JSC::DisallowVMReentry::scopeReentryCount):
2520         (JSC::DisallowVMReentry::setScopeReentryCount):
2521         * runtime/InitializeThreading.cpp:
2522         (JSC::initializeThreading):
2523         * runtime/JSArray.cpp:
2524         (JSC::JSArray::tryCreateUninitializedRestricted):
2525         (JSC::JSArray::fastSlice):
2526         (JSC::JSArray::tryCreateForInitializationPrivate): Deleted.
2527         * runtime/JSArray.h:
2528         (JSC::JSArray::tryCreateUninitializedRestricted):
2529         (JSC::JSArray::tryCreate):
2530         (JSC::constructArray):
2531         (JSC::constructArrayNegativeIndexed):
2532         (JSC::JSArray::tryCreateForInitializationPrivate): Deleted.
2533         (JSC::createArrayButterfly): Deleted.
2534         * runtime/JSCellInlines.h:
2535         (JSC::allocateCell):
2536         * runtime/JSObject.h:
2537         (JSC::JSObject::initializeIndex):
2538         (JSC::JSObject::initializeIndexWithoutBarrier):
2539         * runtime/ObjectInitializationScope.cpp: Added.
2540         (JSC::ObjectInitializationScope::ObjectInitializationScope):
2541         (JSC::ObjectInitializationScope::~ObjectInitializationScope):
2542         (JSC::ObjectInitializationScope::notifyAllocated):
2543         (JSC::ObjectInitializationScope::verifyPropertiesAreInitialized):
2544         * runtime/ObjectInitializationScope.h: Added.
2545         (JSC::ObjectInitializationScope::ObjectInitializationScope):
2546         (JSC::ObjectInitializationScope::vm):
2547         (JSC::ObjectInitializationScope::notifyAllocated):
2548         * runtime/Operations.h:
2549         (JSC::isScribbledValue):
2550         (JSC::scribble):
2551         * runtime/RegExpMatchesArray.cpp:
2552         (JSC::createEmptyRegExpMatchesArray):
2553         * runtime/RegExpMatchesArray.h:
2554         (JSC::tryCreateUninitializedRegExpMatchesArray):
2555         (JSC::createRegExpMatchesArray):
2556         * runtime/VMEntryScope.cpp:
2557         (JSC::VMEntryScope::VMEntryScope):
2558
2559 2017-04-27  Carlos Garcia Campos  <cgarcia@igalia.com>
2560
2561         [GTK] Remote inspector should support inspecting targets with previous version of backend commands
2562         https://bugs.webkit.org/show_bug.cgi?id=171267
2563
2564         Reviewed by Michael Catanzaro.
2565
2566         Rename GetTargetList DBus method as SetupInspectorClient since this method is actually called only once by
2567         client right after connecting to the server. The method now receives the client backend commands hash as
2568         argument and returns the contents of the backend commands file in case the hash doesn't match with the local
2569         version.
2570
2571         * PlatformGTK.cmake: Add RemoteInspectorUtils to compilation.
2572         * inspector/remote/glib/RemoteInspectorServer.cpp:
2573         (Inspector::RemoteInspectorServer::setupInspectorClient):
2574         * inspector/remote/glib/RemoteInspectorServer.h:
2575         * inspector/remote/glib/RemoteInspectorUtils.cpp: Added.
2576         (Inspector::backendCommands):
2577         (Inspector::backendCommandsHash):
2578         * inspector/remote/glib/RemoteInspectorUtils.h: Added.
2579
2580 2017-04-27  Yusuke Suzuki  <utatane.tea@gmail.com>
2581
2582         [JSC] Handle PhantomSpread in LoadVarargs as the same to the others
2583         https://bugs.webkit.org/show_bug.cgi?id=171262
2584
2585         Reviewed by Saam Barati.
2586
2587         This is follow-up patch after r215720. In that patch, accidentally
2588         we did not apply the same change to LoadVarargs in argument elimination
2589         phase. This patch just does the same rewriting to handle PhantomSpread
2590         correctly.
2591
2592         * dfg/DFGArgumentsEliminationPhase.cpp:
2593
2594 2017-04-26  Joseph Pecoraro  <pecoraro@apple.com>
2595
2596         Web Inspector: Uint8ClampedArray should be treated like an array, not an object
2597         https://bugs.webkit.org/show_bug.cgi?id=171364
2598         <rdar://problem/10873037>
2599
2600         Reviewed by Sam Weinig.
2601
2602         * inspector/JSInjectedScriptHost.cpp:
2603         (Inspector::JSInjectedScriptHost::subtype):
2604         Treat Uint8ClampedArray (like other Typed Arrays) as an array.
2605
2606 2017-04-26  Saam Barati  <sbarati@apple.com>
2607
2608         Print Wasm function index in stack trace
2609         https://bugs.webkit.org/show_bug.cgi?id=171349
2610
2611         Reviewed by JF Bastien.
2612
2613         This patch prints a Callee's index in the function index
2614         space in Error.stack.
2615
2616         This will lead to stack traces that have lines of text like:
2617         wasm function index: 4@[wasm code]
2618
2619         We don't ascribe indices to everything in wasm. Specifically, the
2620         Wasm->JS call stub callee does not get a name, and neither does
2621         the JS -> Wasm entrypoint.
2622
2623         * interpreter/Interpreter.cpp:
2624         (JSC::GetStackTraceFunctor::operator()):
2625         * interpreter/StackVisitor.cpp:
2626         (JSC::StackVisitor::readNonInlinedFrame):
2627         (JSC::StackVisitor::Frame::functionName):
2628         * interpreter/StackVisitor.h:
2629         (JSC::StackVisitor::Frame::wasmFunctionIndex):
2630         * runtime/StackFrame.cpp:
2631         (JSC::StackFrame::functionName):
2632         * runtime/StackFrame.h:
2633         (JSC::StackFrame::StackFrame):
2634         (JSC::StackFrame::wasm):
2635         (JSC::StackFrame::hasBytecodeOffset):
2636         (JSC::StackFrame::bytecodeOffset):
2637         * wasm/WasmBBQPlanInlines.h:
2638         (JSC::Wasm::BBQPlan::initializeCallees):
2639         * wasm/WasmCallee.cpp:
2640         (JSC::Wasm::Callee::Callee):
2641         * wasm/WasmCallee.h:
2642         (JSC::Wasm::Callee::create):
2643         (JSC::Wasm::Callee::index):
2644         * wasm/WasmOMGPlan.cpp:
2645         (JSC::Wasm::OMGPlan::work):
2646
2647 2017-04-26  Keith Miller  <keith_miller@apple.com>
2648
2649         Follow up to r215843
2650         https://bugs.webkit.org/show_bug.cgi?id=171361
2651
2652         Reviewed by Saam Barati.
2653
2654         This patch fixes some style comments Saam didn't get a chance to
2655         request before I landed: https://bugs.webkit.org/show_bug.cgi?id=170134.
2656
2657         It renames Wasm::CodeBlock::m_wasmEntrypoints to
2658         m_wasmIndirectCallEntrypoints, as well as fixes some copyrights and
2659         indentation.
2660
2661         * wasm/WasmBBQPlan.cpp:
2662         * wasm/WasmCodeBlock.cpp:
2663         (JSC::Wasm::CodeBlock::CodeBlock):
2664         * wasm/WasmCodeBlock.h:
2665         (JSC::Wasm::CodeBlock::wasmEntrypointLoadLocationFromFunctionIndexSpace):
2666         * wasm/WasmOMGPlan.cpp:
2667         (JSC::Wasm::OMGPlan::work):
2668         * wasm/WasmTierUpCount.h:
2669         (JSC::Wasm::TierUpCount::TierUpCount):
2670         (JSC::Wasm::TierUpCount::loopDecrement):
2671         (JSC::Wasm::TierUpCount::functionEntryDecrement):
2672         (JSC::Wasm::TierUpCount::shouldStartTierUp):
2673         (JSC::Wasm::TierUpCount::count):
2674
2675 2017-04-26  Saam Barati  <sbarati@apple.com>
2676
2677         ASSERTION FAILED: inIndex != notFound in JSC::invalidParameterInSourceAppender()
2678         https://bugs.webkit.org/show_bug.cgi?id=170924
2679         <rdar://problem/31721052>
2680
2681         Reviewed by Mark Lam.
2682
2683         The error message handler for "in" was searching for the literal
2684         string "in". However, our parser incorrectly allows escaped characters
2685         to be part of keywords. So this is parsed as "in" in JSC: "i\u006E".
2686         It should not be parsed that way. I opened https://bugs.webkit.org/show_bug.cgi?id=171310
2687         to address this issue.
2688         
2689         Regardless, the error message handlers should handle unexpected text gracefully.
2690         All functions that try to augment error messages with the goal of
2691         providing a more textual context for the error message should use
2692         the original error message instead of crashing when they detect
2693         unexpected text.
2694         
2695         This patch also changes the already buggy code that tries to find
2696         the base of a function call. That could would fail for code like this:
2697         "zoo.bar("/abc\)*/");". See https://bugs.webkit.org/show_bug.cgi?id=146304
2698         It would think that the base is "z". However, the algorithm that tries
2699         to find the base can often tell when it fails, and when it does, it should
2700         happily return the approximate text error message instead of thinking
2701         that the base is "z".
2702
2703         * runtime/ExceptionHelpers.cpp:
2704         (JSC::functionCallBase):
2705         (JSC::notAFunctionSourceAppender):
2706         (JSC::invalidParameterInSourceAppender):
2707
2708 2017-04-26  Keith Miller  <keith_miller@apple.com>
2709
2710         WebAssembly: Implement tier up
2711         https://bugs.webkit.org/show_bug.cgi?id=170134
2712
2713         Reviewed by Filip Pizlo.
2714
2715         This patch implements tier up for wasm functions. Unlike with JS
2716         code, wasm code needs to be able to tier up concurrently with the
2717         running code.  Since JS code is synchronous we can always link on
2718         the running thread, wasm, however, can run the same code on more
2719         than one thread. In order to make patching work correctly, we need
2720         to ensure that all patches of callsites are aligned. On ARM we get
2721         this for free since every call is a near call. On X86 we ensure
2722         that the 32-bit relative offset is 32-bit aligned.
2723
2724         This patch also modifies how Wasm::Plan works. Now Plan is a
2725         abstract super class and there are two subclasses, which
2726         correspond to the different tiers of our wasm engine.  The first,
2727         Build Bytecode Quickly (BBQ) tier, roughly does what the old plan
2728         code did before.  The new tier, Optimized Machine code Generation
2729         (OMG), can be called at any point by BBQ code and compiles exactly
2730         one function. Once an OMGPlan finishes it will link it's code
2731         internally then reset the instruction cache of all running wasm
2732         threads, via, a ThreadMessage. Once the instruction caches have
2733         been reset all the other functions will be patched to call the new
2734         code.
2735
2736         * JavaScriptCore.xcodeproj/project.pbxproj:
2737         * assembler/AbstractMacroAssembler.h:
2738         (JSC::AbstractMacroAssembler::ensureCacheLineSpace):
2739         * assembler/CodeLocation.h:
2740         (JSC::CodeLocationThreadSafeNearCall::CodeLocationThreadSafeNearCall):
2741         * assembler/MacroAssemblerARM64.h:
2742         (JSC::MacroAssemblerARM64::threadSafePatchableNearCall):
2743         * assembler/MacroAssemblerX86Common.h:
2744         (JSC::MacroAssemblerX86Common::threadSafeNearCall):
2745         * assembler/MacroAssemblerX86_64.h:
2746         (JSC::MacroAssemblerX86_64::threadSafePatchableNearCall):
2747         * b3/air/AirEmitShuffle.cpp:
2748         (JSC::B3::Air::ShufflePair::inst):
2749         (JSC::B3::Air::ShufflePair::opcode): Deleted.
2750         * b3/air/AirEmitShuffle.h:
2751         * jsc.cpp:
2752         (functionTestWasmModuleFunctions):
2753         * runtime/JSLock.cpp:
2754         (JSC::JSLock::didAcquireLock):
2755         * runtime/Options.h:
2756         * wasm/WasmB3IRGenerator.cpp:
2757         (JSC::Wasm::B3IRGenerator::materializeWasmContext):
2758         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
2759         (JSC::Wasm::B3IRGenerator::constant):
2760         (JSC::Wasm::B3IRGenerator::emitTierUpCheck):
2761         (JSC::Wasm::B3IRGenerator::addLoop):
2762         (JSC::Wasm::B3IRGenerator::addTopLevel):
2763         (JSC::Wasm::B3IRGenerator::addBlock):
2764         (JSC::Wasm::createJSToWasmWrapper):
2765         (JSC::Wasm::parseAndCompile):
2766         * wasm/WasmB3IRGenerator.h:
2767         * wasm/WasmBBQPlan.cpp: Copied from Source/JavaScriptCore/wasm/WasmPlan.cpp.
2768         (JSC::Wasm::BBQPlan::BBQPlan):
2769         (JSC::Wasm::BBQPlan::stateString):
2770         (JSC::Wasm::BBQPlan::moveToState):
2771         (JSC::Wasm::BBQPlan::parseAndValidateModule):
2772         (JSC::Wasm::BBQPlan::prepare):
2773         (JSC::Wasm::BBQPlan::ThreadCountHolder::ThreadCountHolder):
2774         (JSC::Wasm::BBQPlan::ThreadCountHolder::~ThreadCountHolder):
2775         (JSC::Wasm::BBQPlan::compileFunctions):
2776         (JSC::Wasm::BBQPlan::complete):
2777         (JSC::Wasm::BBQPlan::work):
2778         * wasm/WasmBBQPlan.h: Copied from Source/JavaScriptCore/wasm/WasmPlan.h.
2779         * wasm/WasmBBQPlanInlines.h: Copied from Source/JavaScriptCore/wasm/WasmPlanInlines.h.
2780         (JSC::Wasm::BBQPlan::initializeCallees):
2781         * wasm/WasmBinding.cpp:
2782         (JSC::Wasm::wasmToWasm):
2783         * wasm/WasmCallee.h:
2784         (JSC::Wasm::Callee::entrypoint):
2785         * wasm/WasmCodeBlock.cpp:
2786         (JSC::Wasm::CodeBlock::CodeBlock):
2787         * wasm/WasmCodeBlock.h:
2788         (JSC::Wasm::CodeBlock::jsEntrypointCalleeFromFunctionIndexSpace):
2789         (JSC::Wasm::CodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace):
2790         (JSC::Wasm::CodeBlock::wasmEntrypointLoadLocationFromFunctionIndexSpace):
2791         (JSC::Wasm::CodeBlock::tierUpCount):
2792         (JSC::Wasm::CodeBlock::mode):
2793         * wasm/WasmFormat.h:
2794         (JSC::Wasm::CallableFunction::CallableFunction):
2795         (JSC::Wasm::CallableFunction::offsetOfWasmEntrypointLoadLocation):
2796         * wasm/WasmMachineThreads.cpp: Copied from Source/JavaScriptCore/wasm/WasmPlanInlines.h.
2797         (JSC::Wasm::wasmThreads):
2798         (JSC::Wasm::startTrackingCurrentThread):
2799         (JSC::Wasm::resetInstructionCacheOnAllThreads):
2800         * wasm/WasmMachineThreads.h: Copied from Source/JavaScriptCore/wasm/WasmCallee.h.
2801         * wasm/WasmModule.cpp:
2802         (JSC::Wasm::makeValidationResult):
2803         (JSC::Wasm::makeValidationCallback):
2804         (JSC::Wasm::Module::validateSync):
2805         (JSC::Wasm::Module::validateAsync):
2806         * wasm/WasmModule.h:
2807         (JSC::Wasm::Module::codeBlockFor):
2808         * wasm/WasmOMGPlan.cpp: Added.
2809         (JSC::Wasm::OMGPlan::OMGPlan):
2810         (JSC::Wasm::OMGPlan::work):
2811         (JSC::Wasm::runOMGPlanForIndex):
2812         * wasm/WasmOMGPlan.h: Copied from Source/JavaScriptCore/wasm/WasmPlanInlines.h.
2813         * wasm/WasmPlan.cpp:
2814         (JSC::Wasm::Plan::Plan):
2815         (JSC::Wasm::Plan::runCompletionTasks):
2816         (JSC::Wasm::Plan::addCompletionTask):
2817         (JSC::Wasm::Plan::waitForCompletion):
2818         (JSC::Wasm::Plan::tryRemoveVMAndCancelIfLast):
2819         (JSC::Wasm::Plan::fail):
2820         (JSC::Wasm::Plan::stateString): Deleted.
2821         (JSC::Wasm::Plan::moveToState): Deleted.
2822         (JSC::Wasm::Plan::parseAndValidateModule): Deleted.
2823         (JSC::Wasm::Plan::prepare): Deleted.
2824         (JSC::Wasm::Plan::ThreadCountHolder::ThreadCountHolder): Deleted.
2825         (JSC::Wasm::Plan::ThreadCountHolder::~ThreadCountHolder): Deleted.
2826         (JSC::Wasm::Plan::compileFunctions): Deleted.
2827         (JSC::Wasm::Plan::complete): Deleted.
2828         * wasm/WasmPlan.h:
2829         (JSC::Wasm::Plan::exports): Deleted.
2830         (JSC::Wasm::Plan::internalFunctionCount): Deleted.
2831         (JSC::Wasm::Plan::takeModuleInformation): Deleted.
2832         (JSC::Wasm::Plan::takeCallLinkInfos): Deleted.
2833         (JSC::Wasm::Plan::takeWasmToWasmExitStubs): Deleted.
2834         (JSC::Wasm::Plan::hasWork): Deleted.
2835         (JSC::Wasm::Plan::hasBeenPrepared): Deleted.
2836         * wasm/WasmTierUpCount.h: Renamed from Source/JavaScriptCore/wasm/WasmPlanInlines.h.
2837         (JSC::Wasm::TierUpCount::TierUpCount):
2838         (JSC::Wasm::TierUpCount::loopDecrement):
2839         (JSC::Wasm::TierUpCount::functionEntryDecrement):
2840         (JSC::Wasm::TierUpCount::shouldStartTierUp):
2841         (JSC::Wasm::TierUpCount::count):
2842         * wasm/WasmWorklist.cpp:
2843         * wasm/WasmWorklist.h:
2844         (JSC::Wasm::Worklist::nextTicket):
2845         * wasm/js/JSWebAssemblyCodeBlock.cpp:
2846         * wasm/js/JSWebAssemblyCodeBlock.h:
2847         (JSC::JSWebAssemblyCodeBlock::wasmEntrypointLoadLocationFromFunctionIndexSpace):
2848         (JSC::JSWebAssemblyCodeBlock::wasmToJsCallStubForImport):
2849         (JSC::JSWebAssemblyCodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace): Deleted.
2850         * wasm/js/JSWebAssemblyTable.cpp:
2851         (JSC::JSWebAssemblyTable::setFunction):
2852         * wasm/js/WebAssemblyFunction.cpp:
2853         (JSC::WebAssemblyFunction::create):
2854         (JSC::WebAssemblyFunction::WebAssemblyFunction):
2855         * wasm/js/WebAssemblyFunction.h:
2856         (JSC::WebAssemblyFunction::signatureIndex):
2857         (JSC::WebAssemblyFunction::wasmEntrypointLoadLocation):
2858         (JSC::WebAssemblyFunction::callableFunction):
2859         (JSC::WebAssemblyFunction::offsetOfWasmEntrypointLoadLocation):
2860         (JSC::WebAssemblyFunction::wasmEntrypoint): Deleted.
2861         (JSC::WebAssemblyFunction::offsetOfWasmEntrypoint): Deleted.
2862         * wasm/js/WebAssemblyModuleRecord.cpp:
2863         (JSC::WebAssemblyModuleRecord::link):
2864         (JSC::WebAssemblyModuleRecord::evaluate):
2865         * wasm/js/WebAssemblyPrototype.cpp:
2866         (JSC::webAssemblyValidateFunc):
2867         * wasm/js/WebAssemblyWrapperFunction.cpp:
2868         (JSC::WebAssemblyWrapperFunction::WebAssemblyWrapperFunction):
2869         (JSC::WebAssemblyWrapperFunction::create):
2870         * wasm/js/WebAssemblyWrapperFunction.h:
2871         (JSC::WebAssemblyWrapperFunction::signatureIndex):
2872         (JSC::WebAssemblyWrapperFunction::wasmEntrypointLoadLocation):
2873         (JSC::WebAssemblyWrapperFunction::callableFunction):
2874         (JSC::WebAssemblyWrapperFunction::wasmEntrypoint): Deleted.
2875
2876 2017-04-26  Caitlin Potter  <caitp@igalia.com>
2877
2878         [JSC] fix RETURN_IF_EXCEPTION() placement in ownPropertyKeys()
2879         https://bugs.webkit.org/show_bug.cgi?id=171330
2880
2881         Reviewed by Mark Lam.
2882
2883         Ensure RETURN_IF_EXCEPTION() following invokation of the
2884         filterPropertyIfNeeded() lambda.
2885
2886         * runtime/ObjectConstructor.cpp:
2887         (JSC::ownPropertyKeys):
2888
2889 2017-04-26  Caitlin Potter  <caitp@igalia.com>
2890
2891         [JSC] Object.keys() must discard property names with no PropertyDescriptor
2892         https://bugs.webkit.org/show_bug.cgi?id=171291
2893
2894         Reviewed by Yusuke Suzuki.
2895
2896         Proxy objects can produce an arbitrary list of property names from the
2897         "ownKeys" trap, however the Object.keys() algorithm is required to
2898         discard names which do not have a PropertyDescriptor. This also
2899         applies to other uses of the EnumerableOwnProperties() algorithm
2900         (https://tc39.github.io/ecma262/#sec-enumerableownproperties)
2901
2902         Related to https://bugs.chromium.org/p/v8/issues/detail?id=6290
2903
2904         * runtime/ObjectConstructor.cpp:
2905         (JSC::ownPropertyKeys):
2906
2907 2017-04-25  Andy VanWagoner  <thetalecrafter@gmail.com>
2908
2909         Unhandled enumeration values in IntlDateTimeFormat.cpp
2910         https://bugs.webkit.org/show_bug.cgi?id=171241
2911
2912         Reviewed by JF Bastien.
2913
2914         Added some missing cases of the UDateFormatField to partTypeString,
2915         and made them conditional to the ICU version that added them.
2916         This should remove the warnings that appear on platform builds using the
2917         newer system ICU headers.
2918
2919         * runtime/IntlDateTimeFormat.cpp:
2920         (JSC::IntlDateTimeFormat::partTypeString):
2921
2922 2017-04-25  Commit Queue  <commit-queue@webkit.org>
2923
2924         Unreviewed, rolling out r215476.
2925         https://bugs.webkit.org/show_bug.cgi?id=171304
2926
2927         "It broke JSBench" (Requested by saamyjoon on #webkit).
2928
2929         Reverted changeset:
2930
2931         "[ES6]. Implement Annex B.3.3 function hoisting rules for
2932         eval"
2933         https://bugs.webkit.org/show_bug.cgi?id=163208
2934         http://trac.webkit.org/changeset/215476
2935
2936 2017-04-25  Saam Barati  <sbarati@apple.com>
2937
2938         JSArray::isArrayPrototypeIteratorProtocolFastAndNonObservable is wrong because it does not do the necessary checks on the base object
2939         https://bugs.webkit.org/show_bug.cgi?id=171150
2940         <rdar://problem/31771880>
2941
2942         Reviewed by Sam Weinig.
2943
2944         This patch fixes a huge oversight from the patch that introduced
2945         op_spread/Spread. The original patch did not account for the
2946         base object having Symbol.iterator or getters that could
2947         change the iterator protocol. This patch fixes the oversight both
2948         in the C code, as well as the DFG/FTL backends. We only perform
2949         the memcpy version of spread if we've proven that it's guaranteed
2950         to be side-effect free (no indexed getters), and if the iterator
2951         protocol is guaranteed to be the original protocol. To do this, we
2952         must prove that:
2953         1. The protocol on Array.prototype hasn't changed (this is the same as the
2954         introductory patch for op_spread).
2955         2. The base object's __proto__ is Array.prototype
2956         3. The base object does not have indexed getters
2957         4. The base object does not have Symbol.iterator property.
2958
2959         * dfg/DFGGraph.cpp:
2960         (JSC::DFG::Graph::canDoFastSpread):
2961         * dfg/DFGGraph.h:
2962         * dfg/DFGSpeculativeJIT.cpp:
2963         (JSC::DFG::SpeculativeJIT::compileSpread):
2964         * ftl/FTLLowerDFGToB3.cpp:
2965         (JSC::FTL::DFG::LowerDFGToB3::compileSpread):
2966         * runtime/JSArray.cpp:
2967         (JSC::JSArray::isIteratorProtocolFastAndNonObservable):
2968         * runtime/JSArray.h:
2969         * runtime/JSArrayInlines.h:
2970         (JSC::JSArray::isIteratorProtocolFastAndNonObservable): Deleted.
2971         * runtime/JSGlobalObject.h:
2972         * runtime/JSGlobalObjectInlines.h:
2973         (JSC::JSGlobalObject::isArrayPrototypeIteratorProtocolFastAndNonObservable):
2974         (JSC::JSGlobalObject::isArrayIteratorProtocolFastAndNonObservable): Deleted.
2975
2976 2017-04-25  Mark Lam  <mark.lam@apple.com>
2977
2978         Array.prototype.slice() should ensure that end >= begin.
2979         https://bugs.webkit.org/show_bug.cgi?id=170989
2980         <rdar://problem/31705652>
2981
2982         Reviewed by Saam Barati.
2983
2984         * runtime/ArrayPrototype.cpp:
2985         (JSC::arrayProtoFuncSlice):
2986
2987 2017-04-25  Don Olmstead  <don.olmstead@am.sony.com>
2988
2989         [Win] Use Clang's __has_declspec_attribute for export macros
2990         https://bugs.webkit.org/show_bug.cgi?id=171240
2991
2992         Reviewed by Alex Christensen.
2993
2994         * runtime/JSExportMacros.h:
2995
2996 2017-04-25  Saam Barati  <sbarati@apple.com>
2997
2998         Unreviewed. Attempt armv7k build fix after r215720
2999
3000         I think we're just missing an include for the definition of ExecState::r().
3001
3002         * runtime/JSFixedArray.cpp:
3003
3004 2017-04-25  Daniel Bates  <dabates@apple.com>
3005
3006         [Cocoa][Win] Enable of X-Content-Type-Options: nosniff header
3007         https://bugs.webkit.org/show_bug.cgi?id=136452
3008         <rdar://problem/23412620>
3009
3010         Reviewed by Brent Fulgham.
3011
3012         Enable X-Content-Type-Options: nosniff on Mac, iOS and Windows platforms.
3013
3014         * Configurations/FeatureDefines.xcconfig:
3015
3016 2017-04-25  Mark Lam  <mark.lam@apple.com>
3017
3018         Local CSE wrongly CSEs array accesses with different result types.
3019         https://bugs.webkit.org/show_bug.cgi?id=170990
3020         <rdar://problem/31705945>
3021
3022         Reviewed by Saam Barati.
3023
3024         The fix is to use different LocationKind enums for the different type of array
3025         result types.  This makes the HeapLocation values different based on the result
3026         types, and allows CSE to discern between them.
3027
3028         * dfg/DFGCSEPhase.cpp:
3029         * dfg/DFGClobberize.h:
3030         (JSC::DFG::clobberize):
3031         * dfg/DFGHeapLocation.cpp:
3032         (WTF::printInternal):
3033         * dfg/DFGHeapLocation.h:
3034         (JSC::DFG::indexedPropertyLocForResultType):
3035
3036 2017-04-25  Mark Lam  <mark.lam@apple.com>
3037
3038         Make DFG SpeculatedType dumps easier to read.
3039         https://bugs.webkit.org/show_bug.cgi?id=171280
3040
3041         Reviewed by Saam Barati.
3042
3043         Adding a pretty printer to insert |s between each type string and changing the
3044         dumped strings to match the SpeculatedType names case-wise.
3045
3046         * bytecode/SpeculatedType.cpp:
3047         (JSC::PrettyPrinter::PrettyPrinter):
3048         (JSC::PrettyPrinter::print):
3049         (JSC::dumpSpeculation):
3050         * bytecode/SpeculatedType.h:
3051
3052 2017-04-25  JF Bastien  <jfbastien@apple.com>
3053
3054         lowerStackArgs: check Arg::addr.isValidForm when falling back to SP offsets
3055         https://bugs.webkit.org/show_bug.cgi?id=171278
3056
3057         Reviewed by Filip Pizlo.
3058
3059         lowerStackArgs checked that the FP offsets it tries to generate
3060         are valid form, but didn't check that the fallback was valid
3061         form. This lead to stackAddr's assertion being dead, and the
3062         MaroAssembler asserting way later on move / add when handed a huge
3063         immediate.
3064
3065         * b3/air/AirArg.cpp:
3066         (JSC::B3::Air::Arg::stackAddrImpl):
3067
3068 2017-04-25  Zan Dobersek  <zdobersek@igalia.com>
3069
3070         [aarch64] moveConditionally32(), moveConditionallyTest32() should move from/to 64-bit registers
3071         https://bugs.webkit.org/show_bug.cgi?id=170891
3072
3073         Reviewed by Saam Barati.
3074
3075         moveConditionally32() and moveConditionallyTest32() operations in
3076         MacroAssemblerARM64 properly perform comparisons and tests on 32-bit
3077         values, but end up performing the moves from and to 32-bit registers.
3078
3079         Move operations should instead be done on 64-bit registers, just like
3080         on the X86_64 platform. This is achieved by specifying 64 as the data
3081         size for the csel instructions.
3082
3083         * assembler/MacroAssemblerARM64.h:
3084         (JSC::MacroAssemblerARM64::moveConditionally32):
3085         (JSC::MacroAssemblerARM64::moveConditionallyTest32):
3086
3087 2017-04-24  Joseph Pecoraro  <pecoraro@apple.com>
3088
3089         test262: test262/test/language/expressions/object/method-definition/early-errors-object-method-duplicate-parameters.js
3090         https://bugs.webkit.org/show_bug.cgi?id=171190
3091
3092         Reviewed by Saam Barati.
3093
3094         * bytecompiler/BytecodeGenerator.cpp:
3095         (JSC::BytecodeGenerator::BytecodeGenerator):
3096         (JSC::BytecodeGenerator::emitNewFunctionExpressionCommon):
3097         (JSC::BytecodeGenerator::emitNewFunction):
3098         * bytecompiler/NodesCodegen.cpp:
3099         (JSC::FunctionNode::emitBytecode):
3100         (JSC::Scope::setSourceParseMode):
3101         * parser/ParserModes.h:
3102         (JSC::isFunctionParseMode):
3103         (JSC::isMethodParseMode):
3104         (JSC::isGeneratorOrAsyncFunctionWrapperParseMode):
3105         (JSC::isGeneratorParseMode):
3106         (JSC::isGeneratorWrapperParseMode):
3107         * runtime/FunctionExecutable.h:
3108         * runtime/JSFunction.cpp:
3109         (JSC::JSFunction::getOwnPropertySlot):
3110         Add a new GeneratorWrapperMethodMode parse mode. The other function types
3111         (async, arrow) already have a FunctionMode and a MethodMode. Give
3112         generators one as well. This lets isMethodParseMode actually be accurate.
3113
3114         * parser/Parser.cpp:
3115         (JSC::Parser<LexerType>::parseInner):
3116         (JSC::Parser<LexerType>::isArrowFunctionParameters):
3117         (JSC::Parser<LexerType>::parseFormalParameters):
3118         (JSC::stringForFunctionMode):
3119         (JSC::Parser<LexerType>::parseFunctionParameters):
3120         (JSC::Parser<LexerType>::parseFunctionInfo):
3121         (JSC::Parser<LexerType>::parseClass):
3122         (JSC::Parser<LexerType>::parsePropertyMethod):
3123         * parser/Parser.h:
3124         Add a duplicate parameter failure if there are duplicate parameters
3125         in method syntax.
3126
3127 2017-04-24  Andy VanWagoner  <thetalecrafter@gmail.com>
3128
3129         Clean up ICU headers
3130         https://bugs.webkit.org/show_bug.cgi?id=170997
3131
3132         Reviewed by JF Bastien.
3133
3134         Update all icu headers to 55.1
3135
3136         * icu/LICENSE: Update copyright
3137         * icu/README: Explain ICU headers for OS X better
3138         * icu/unicode/localpointer.h:
3139         (LocalPointer::LocalPointer):
3140         (LocalPointer::adoptInsteadAndCheckErrorCode):
3141         * icu/unicode/platform.h:
3142         * icu/unicode/putil.h:
3143         * icu/unicode/ucal.h:
3144         * icu/unicode/uchar.h:
3145         * icu/unicode/ucnv.h:
3146         * icu/unicode/ucol.h:
3147         * icu/unicode/uconfig.h:
3148         * icu/unicode/ucurr.h:
3149         * icu/unicode/udatpg.h:
3150         * icu/unicode/udisplaycontext.h:
3151         * icu/unicode/uformattable.h:
3152         * icu/unicode/uloc.h:
3153         * icu/unicode/umachine.h:
3154         * icu/unicode/unum.h:
3155         * icu/unicode/unumsys.h:
3156         * icu/unicode/urename.h:
3157         * icu/unicode/uscript.h:
3158         * icu/unicode/uset.h:
3159         * icu/unicode/ustring.h:
3160         * icu/unicode/utf8.h:
3161         * icu/unicode/utypes.h:
3162
3163 2017-04-24  Yusuke Suzuki  <utatane.tea@gmail.com>
3164
3165         [JSC] Use JSFixedArray directly when using call_varargs
3166         https://bugs.webkit.org/show_bug.cgi?id=171057
3167
3168         Reviewed by Saam Barati.
3169
3170         Previously we always emit new_array_with_spread when calling call(...args).
3171         But this array is unnecessary if varargs operation can handle Spread directly.
3172
3173         This patch implements a peep-hole optimization in the bytecode compiler layer
3174         to omit new_array_with_spread. This is very simple and effective because this
3175         peep-hole optimization is quite common when using (...args) style calls and
3176         this optimization works all the tiers. While we can implement the phase to
3177         omit this NewArrayWithSpread in argument elimination phase, it only works
3178         for FTL. While such an optimization can work with complex data flow, this
3179         peep-hole optimization can optimize a common case easily.
3180
3181         For now, Spread and PhantomSpread can be directly drained by CallVarargs
3182         and LoadVarargs related operations. We modify DFG and FTL to handle this correctly.
3183
3184         This shows six-speed improvement.
3185
3186             spread.es6                 89.4300+-2.0236     ^     69.6015+-1.7278        ^ definitely 1.2849x faster
3187             spread-generator.es6      344.7879+-5.9147     ^    331.2712+-6.8610        ^ definitely 1.0408x faster
3188
3189         * bytecompiler/BytecodeGenerator.cpp:
3190         (JSC::BytecodeGenerator::emitCall):
3191         (JSC::BytecodeGenerator::emitConstruct):
3192         * dfg/DFGArgumentsEliminationPhase.cpp:
3193         * dfg/DFGPreciseLocalClobberize.h:
3194         (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
3195         * ftl/FTLLowerDFGToB3.cpp:
3196         (JSC::FTL::DFG::LowerDFGToB3::compileSpread):
3197         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread):
3198         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
3199         (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargs):
3200         (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargsWithSpread):
3201         * interpreter/Interpreter.cpp:
3202         (JSC::sizeOfVarargs):
3203         (JSC::loadVarargs):
3204         * parser/Nodes.h:
3205         (JSC::ArrayNode::elements):
3206         * runtime/JSFixedArray.cpp:
3207         (JSC::JSFixedArray::copyToArguments):
3208         * runtime/JSFixedArray.h:
3209
3210 2017-04-24  Yusuke Suzuki  <utatane.tea@gmail.com>
3211
3212         [WTF] Move JSC tools/StackTrace to WTF and unify stack trace dump code
3213         https://bugs.webkit.org/show_bug.cgi?id=171199
3214
3215         Reviewed by Mark Lam.
3216
3217         This patch adds a utility method to produce demangled names with dladdr.
3218         It fixes several memory leaks because the result of abi::__cxa_demangle()
3219         needs to be `free`-ed.
3220
3221         * CMakeLists.txt:
3222         * JavaScriptCore.xcodeproj/project.pbxproj:
3223         * inspector/JSGlobalObjectInspectorController.cpp:
3224         (Inspector::JSGlobalObjectInspectorController::appendAPIBacktrace):
3225         * runtime/SamplingProfiler.cpp:
3226         (JSC::SamplingProfiler::StackFrame::displayName):
3227         * tools/CellProfile.h:
3228         * tools/CodeProfile.cpp:
3229         (JSC::CodeProfile::report):
3230         (JSC::symbolName): Deleted.
3231
3232 2017-04-24  Joseph Pecoraro  <pecoraro@apple.com>
3233
3234         Web Inspector: ObjC RWIProtocol codegen should better handle optional members
3235         https://bugs.webkit.org/show_bug.cgi?id=171251
3236         <rdar://problem/31697002>
3237
3238         Reviewed by Brian Burg.
3239
3240         * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
3241         (ObjCProtocolTypesImplementationGenerator._generate_getter_for_member):
3242         * inspector/scripts/codegen/objc_generator.py:
3243         (ObjCGenerator.protocol_to_objc_expression_for_member):
3244         (ObjCGenerator.protocol_to_objc_code_block_for_object_member):
3245         Always be safe and nil check object property accesses, optional or not.
3246
3247         * inspector/scripts/tests/generic/expected/type-declaration-object-type.json-result:
3248         * inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result:
3249         Rebaselined inspector generator tests.
3250
3251 2017-04-24  Saam Barati  <sbarati@apple.com>
3252
3253         ASSERTION FAILED: m_table seen with workers/wasm-hashset LayoutTests
3254         https://bugs.webkit.org/show_bug.cgi?id=171119
3255         <rdar://problem/31760635>
3256
3257         Reviewed by Keith Miller.
3258
3259         The HashSet of timer set notification callbacks can be accessed
3260         and augmented simultaneously from different threads. e.g, the worker
3261         thread can augment it while the wasm compilation thread will
3262         access it. Therefore, accesses must be guarded by a lock.
3263
3264         * runtime/JSRunLoopTimer.cpp:
3265         (JSC::JSRunLoopTimer::scheduleTimer):
3266         (JSC::JSRunLoopTimer::addTimerSetNotification):
3267         (JSC::JSRunLoopTimer::removeTimerSetNotification):
3268         * runtime/JSRunLoopTimer.h:
3269
3270 2017-04-24  Joseph Pecoraro  <pecoraro@apple.com>
3271
3272         test262: test262/test/language/computed-property-names/class/static/getter-prototype.js
3273         https://bugs.webkit.org/show_bug.cgi?id=170897
3274
3275         Reviewed by Saam Barati.
3276
3277         * parser/ASTBuilder.h:
3278         (JSC::ASTBuilder::createArguments):
3279         (JSC::ASTBuilder::createArgumentsList):
3280         Reorder so all the createProperty methods are grouped together.
3281
3282         * parser/Parser.h:
3283         * parser/Parser.cpp:
3284         (JSC::Parser<LexerType>::parseClass):
3285         (JSC::Parser<LexerType>::parseProperty):
3286         (JSC::Parser<LexerType>::parseGetterSetter):
3287         Refine the conditions for syntax errors for getter/setter
3288         properties names. "prototype" is not allowed as a static
3289         and "constructor" is not all when non-static.
3290
3291         * runtime/JSObject.cpp:
3292         (JSC::JSObject::putGetter):
3293         (JSC::JSObject::putSetter):
3294         Throw exceptions. These methods are only used by this path
3295         via op_put_getter_by_val / op_put_setter_by_val.
3296
3297 2017-04-24  Joseph Pecoraro  <pecoraro@apple.com>
3298
3299         test262: test262/test/language/statements/for-of/dstr-array-elem-init-fn-name-arrow.js
3300         https://bugs.webkit.org/show_bug.cgi?id=171160
3301
3302         Reviewed by JF Bastien.
3303
3304         * parser/ASTBuilder.h:
3305         (JSC::ASTBuilder::tryInferNameInPattern):
3306         (JSC::ASTBuilder::tryInferNameInPatternWithIdentifier):
3307         We supported getting the name from a BindingNode.
3308         We extend this to support getting the name from a
3309         ResolveNode inside of an AssignmentElementNode.
3310
3311         * parser/Nodes.h:
3312         (JSC::DestructuringPatternNode::isAssignmentElementNode):
3313         (JSC::AssignmentElementNode::isAssignmentElementNode):
3314         Make it possible to identify an assignment element node.
3315
3316 2017-04-24  Alex Christensen  <achristensen@webkit.org>
3317
3318         Reduce copies and allocations in SharedBuffer::append
3319         https://bugs.webkit.org/show_bug.cgi?id=170956
3320
3321         Reviewed by Andreas Kling.
3322
3323         * runtime/ArrayBuffer.h:
3324
3325 2017-04-24  Carlos Garcia Campos  <cgarcia@igalia.com>
3326
3327         [GTK] Switch to use ENABLE_REMOTE_INSPECTOR instead of ENABLE_INSPECTOR_SERVER for the remote inspector
3328         https://bugs.webkit.org/show_bug.cgi?id=166680
3329
3330         Reviewed by Michael Catanzaro.
3331
3332         Add GTK+ port implementation of RemoteInspector.
3333
3334         * PlatformGTK.cmake:
3335         * inspector/remote/RemoteConnectionToTarget.h:
3336         * inspector/remote/RemoteInspector.h:
3337         * inspector/remote/glib/RemoteConnectionToTargetGlib.cpp: Added.
3338         (Inspector::RemoteConnectionToTarget::RemoteConnectionToTarget):
3339         (Inspector::RemoteConnectionToTarget::~RemoteConnectionToTarget):
3340         (Inspector::RemoteConnectionToTarget::setup):
3341         (Inspector::RemoteConnectionToTarget::sendMessageToTarget):
3342         (Inspector::RemoteConnectionToTarget::close):
3343         (Inspector::RemoteConnectionToTarget::targetClosed):
3344         (Inspector::RemoteConnectionToTarget::targetIdentifier):
3345         (Inspector::RemoteConnectionToTarget::sendMessageToFrontend):
3346         * inspector/remote/glib/RemoteInspectorGlib.cpp: Added.
3347         (Inspector::RemoteInspector::singleton):
3348         (Inspector::RemoteInspector::RemoteInspector):
3349         (Inspector::RemoteInspector::start):
3350         (Inspector::RemoteInspector::stopInternal):
3351         (Inspector::RemoteInspector::setupConnection):
3352         (Inspector::dbusConnectionCallAsyncReadyCallback):
3353         (Inspector::RemoteInspector::listingForInspectionTarget):
3354         (Inspector::RemoteInspector::listingForAutomationTarget):
3355         (Inspector::RemoteInspector::pushListingsNow):
3356         (Inspector::RemoteInspector::pushListingsSoon):
3357         (Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
3358         (Inspector::RemoteInspector::sendAutomaticInspectionCandidateMessage):
3359         (Inspector::RemoteInspector::sendMessageToRemote):
3360         (Inspector::RemoteInspector::receivedGetTargetListMessage):
3361         (Inspector::RemoteInspector::receivedSetupMessage):
3362         (Inspector::RemoteInspector::receivedDataMessage):
3363         (Inspector::RemoteInspector::receivedCloseMessage):
3364         (Inspector::RemoteInspector::setup):
3365         (Inspector::RemoteInspector::sendMessageToTarget):
3366         (Inspector::RemoteInspector::requestAutomationSession):
3367         * inspector/remote/glib/RemoteInspectorServer.cpp: Added.
3368         (Inspector::generateConnectionID):
3369         (Inspector::RemoteInspectorServer::singleton):
3370         (Inspector::RemoteInspectorServer::~RemoteInspectorServer):
3371         (Inspector::RemoteInspectorServer::interfaceInfo):
3372         (Inspector::RemoteInspectorServer::start):
3373         (Inspector::RemoteInspectorServer::newConnectionCallback):
3374         (Inspector::RemoteInspectorServer::connectionClosedCallback):
3375         (Inspector::RemoteInspectorServer::newConnection):
3376         (Inspector::dbusConnectionCallAsyncReadyCallback):
3377         (Inspector::RemoteInspectorServer::setTargetList):
3378         (Inspector::RemoteInspectorServer::clientConnectionClosedCallback):
3379         (Inspector::RemoteInspectorServer::getTargetList):
3380         (Inspector::RemoteInspectorServer::setup):
3381         (Inspector::RemoteInspectorServer::close):
3382         (Inspector::RemoteInspectorServer::clientConnectionClosed):
3383         (Inspector::RemoteInspectorServer::connectionClosed):
3384         (Inspector::RemoteInspectorServer::sendMessageToBackend):
3385         (Inspector::RemoteInspectorServer::sendMessageToFrontend):
3386         (Inspector::RemoteInspectorServer::startAutomationSession):
3387         * inspector/remote/glib/RemoteInspectorServer.h: Added.
3388         (Inspector::RemoteInspectorServer::isRunning):
3389
3390 2017-04-24  Joseph Pecoraro  <pecoraro@apple.com>
3391
3392         test262: test262/test/language/expressions/generators/yield-as-label.js
3393         https://bugs.webkit.org/show_bug.cgi?id=170979
3394
3395         Reviewed by Saam Barati.
3396
3397         * parser/Parser.cpp:
3398         (JSC::Parser<LexerType>::parseVariableDeclarationList):
3399         (JSC::Parser<LexerType>::parseDestructuringPattern):
3400         (JSC::Parser<LexerType>::parseFormalParameters):
3401         Converge on "Cannot" instead of "Can't" in error messages.
3402
3403         (JSC::Parser<LexerType>::parseFunctionInfo):
3404         Disallow "yield" as the generator function name in function expressions.
3405         This refers to the difference between Declaration and Expression, where
3406         only GeneratorExpression explicitly has [+Yield] disallowing yield for
3407         the generator name:
3408
3409             GeneratorDeclaration[Yield, Await, Default]:
3410                 function * BindingIdentifier[?Yield, ?Await] ...
3411
3412             GeneratorExpression:
3413                 function * BindingIdentifier[+Yield, ~Await]opt ...
3414
3415         (JSC::Parser<LexerType>::parseExpressionOrLabelStatement):
3416         Disallow "yield" as a label name in strict mode or inside a generator.
3417
3418         (JSC::Parser<LexerType>::parseProperty):
3419         Disallow "yield" or any keyword in object literal shorthands.
3420
3421         * parser/Parser.h:
3422         (JSC::Parser::getToken):
3423         (JSC::Parser::isDisallowedIdentifierLet):
3424         (JSC::Parser::isDisallowedIdentifierYield):
3425         (JSC::Parser::disallowedIdentifierLetReason):
3426         (JSC::Parser::disallowedIdentifierYieldReason):
3427         Follow pattern for improved error messages based on context.
3428
3429 2017-04-23  Commit Queue  <commit-queue@webkit.org>
3430
3431         Unreviewed, rolling out r215674.
3432         https://bugs.webkit.org/show_bug.cgi?id=171212
3433
3434         Possible unintended commit. This patch was on the wrong bug.
3435         (Requested by JoePeck on #webkit).
3436
3437         Reverted changeset:
3438
3439         "test262: test262/test/language/expressions/generators/yield-
3440         as-label.js"
3441         https://bugs.webkit.org/show_bug.cgi?id=170979
3442         http://trac.webkit.org/changeset/215674
3443
3444 2017-04-23  Joseph Pecoraro  <pecoraro@apple.com>
3445
3446         test262: test262/test/built-ins/Number/prototype/toPrecision/nan.js
3447         https://bugs.webkit.org/show_bug.cgi?id=171197
3448
3449         Reviewed by Saam Barati.
3450
3451         * runtime/NumberPrototype.cpp:
3452         (JSC::numberProtoFuncToExponential):
3453         (JSC::numberProtoFuncToFixed):
3454         (JSC::numberProtoFuncToPrecision):
3455         Refine the order of operations to match the spec.
3456
3457 2017-04-23  Joseph Pecoraro  <pecoraro@apple.com>
3458
3459         test262: test262/test/language/expressions/generators/yield-as-label.js
3460         https://bugs.webkit.org/show_bug.cgi?id=170979
3461
3462         Reviewed by Saam Barati.
3463
3464         * parser/Parser.cpp:
3465         (JSC::Parser<LexerType>::parseVariableDeclarationList):
3466         (JSC::Parser<LexerType>::parseDestructuringPattern):
3467         (JSC::Parser<LexerType>::parseFormalParameters):
3468         Converge on "Cannot" instead of "Can't" in error messages.
3469
3470         (JSC::Parser<LexerType>::parseFunctionInfo):
3471         Disallow "yield" as the generator function name in function expressions.
3472         This refers to the difference between Declaration and Expression, where
3473         only GeneratorExpression explicitly has [+Yield] disallowing yield for
3474         the generator name:
3475
3476             GeneratorDeclaration[Yield, Await, Default]:
3477                 function * BindingIdentifier[?Yield, ?Await] ...
3478
3479             GeneratorExpression:
3480                 function * BindingIdentifier[+Yield, ~Await]opt ...
3481
3482         (JSC::Parser<LexerType>::parseExpressionOrLabelStatement):
3483         Disallow "yield" as a label name in strict mode or inside a generator.
3484
3485         (JSC::Parser<LexerType>::parseProperty):
3486         Disallow "yield" or any keyword in object literal shorthands.
3487
3488         * parser/Parser.h:
3489         (JSC::Parser::getToken):
3490         (JSC::Parser::isDisallowedIdentifierLet):
3491         (JSC::Parser::isDisallowedIdentifierYield):
3492         (JSC::Parser::disallowedIdentifierLetReason):
3493         (JSC::Parser::disallowedIdentifierYieldReason):
3494         Follow pattern for improved error messages based on context.
3495
3496 2017-04-23  Joseph Pecoraro  <pecoraro@apple.com>
3497
3498         test262: test262/test/built-ins/Number/parseFloat.js
3499         https://bugs.webkit.org/show_bug.cgi?id=171193
3500
3501         Reviewed by Yusuke Suzuki.
3502
3503         * runtime/CommonIdentifiers.h:
3504         * runtime/JSGlobalObject.cpp:
3505         (JSC::JSGlobalObject::init):
3506         (JSC::JSGlobalObject::visitChildren):
3507         * runtime/JSGlobalObject.h:
3508         (JSC::JSGlobalObject::parseFloatFunction):
3509         Expose parseFloat on the global object to be shared with Number constructor.
3510
3511         * runtime/NumberConstructor.cpp:
3512         (JSC::NumberConstructor::finishCreation):
3513         parseFloat uses the same value as the global parseFloat.
3514
3515 2017-04-22  Yusuke Suzuki  <utatane.tea@gmail.com>
3516
3517         [JSC] Use DoublyLinkedList for MachineThread
3518         https://bugs.webkit.org/show_bug.cgi?id=171171
3519
3520         Reviewed by Mark Lam.
3521
3522         MachineThread can use WTF::DoublyLinkedList to simplify
3523         its implementation. We should not use Vector<> etc. since
3524         we do not want to call allocations during suspending and
3525         resuming threads.
3526
3527         * heap/MachineStackMarker.cpp:
3528         (JSC::MachineThreads::MachineThreads):
3529         (JSC::MachineThreads::~MachineThreads):
3530         (JSC::MachineThreads::addCurrentThread):
3531         (JSC::MachineThreads::removeThreadIfFound):
3532         (JSC::MachineThreads::MachineThread::MachineThread):
3533         (JSC::MachineThreads::tryCopyOtherThreadStacks):
3534         * heap/MachineStackMarker.h:
3535         (JSC::MachineThreads::threadsListHead):
3536         * runtime/SamplingProfiler.cpp:
3537         (JSC::FrameWalker::isValidFramePointer):
3538         * runtime/VMTraps.cpp:
3539         (JSC::findActiveVMAndStackBounds):
3540
3541 2017-04-22  JF Bastien  <jfbastien@apple.com>
3542
3543         WebAssembly: Module.exports, Module.imports, Module.customSections are wrong
3544         https://bugs.webkit.org/show_bug.cgi?id=171078
3545
3546         Reviewed by Saam Barati.
3547
3548         They're static properties of Module, not instance properties of a module.
3549         https://github.com/WebAssembly/design/blob/master/JS.md#webassemblymoduleexports
3550
3551         * wasm/js/WebAssemblyModuleConstructor.cpp:
3552         (JSC::webAssemblyModuleCustomSections):
3553         (JSC::webAssemblyModuleImports):
3554         (JSC::webAssemblyModuleExports):
3555         * wasm/js/WebAssemblyModulePrototype.cpp:
3556         (JSC::webAssemblyModuleProtoCustomSections): Deleted.
3557         (JSC::webAssemblyModuleProtoImports): Deleted.
3558         (JSC::webAssemblyModuleProtoExports): Deleted.
3559
3560 2017-04-21  Saam Barati  <sbarati@apple.com>
3561
3562         SharedArrayBuffer-opt.js fails with Briggs
3563         https://bugs.webkit.org/show_bug.cgi?id=170948
3564         <rdar://problem/31740568>
3565
3566         Reviewed by Michael Saboff.
3567
3568         The bug was not actually with Briggs, but instead was with
3569         our X86-64 MacroAssembler. Michael fixed the bug here:
3570         https://trac.webkit.org/changeset/215618/webkit
3571         
3572         The issue was we weren't adding the REX byte for AtomicXchg8,
3573         leading to the incorrect encoding for the result register depending
3574         on which register it was. If you look at this code, you'll see the issue:
3575
3576           Int32 @38 = AtomicXchg(@59, @64, width = 8, range = 0, fenceRange = 0, ControlDependent|Fence|Writes:0|Reads:0, DFG:@49)
3577               AtomicXchg8 %rsi, (%rax,%rdx), @38
3578                   0x2dcb5bc0015e: lock xchg %dh, (%rax,%rdx)
3579           Int32 @66 = Const32(255, DFG:@49)
3580           Int32 @67 = BitAnd(@38, $255(@66), DFG:@49)
3581               ZeroExtend8To32 %rsi, %rax, @67
3582                   0x2dcb5bc00162: movzx %sil, %eax
3583
3584         Air thought the result was in the lower 8 bits of %rsi,
3585         however, the code we emitted stored it in the [8-15] bits
3586         of %rdx. Since this issue is fixed, I'm turning Briggs back
3587         on.
3588
3589         * b3/air/AirAllocateRegistersByGraphColoring.h:
3590         (JSC::B3::Air::useIRC):
3591
3592 2017-04-20  Mark Lam  <mark.lam@apple.com>
3593
3594         Refactor MASM probe to allow printing of custom types.
3595         https://bugs.webkit.org/show_bug.cgi?id=171101
3596
3597         Reviewed by JF Bastien.
3598
3599         For example, this allows us to add MASM printing of CodeBlock* and Air::Args.
3600
3601         In general, MASM print can be used like dataLog, except that it generates JITted
3602         code for doing the dataLogging later when the JITted code runs.  MASM print can
3603         print any value type that a specialized Printer template or a setPrinter()
3604         function implemented for that type.
3605
3606         * CMakeLists.txt:
3607         * JavaScriptCore.xcodeproj/project.pbxproj:
3608         * assembler/MacroAssembler.h:
3609
3610         * assembler/MacroAssemblerPrinter.cpp:
3611         (JSC::Printer::printAllRegisters):
3612         (JSC::Printer::printPCRegister):
3613         (JSC::Printer::printRegisterID):
3614         (JSC::Printer::printFPRegisterID):
3615         (JSC::Printer::printAddress):
3616         (JSC::Printer::printMemory):
3617         (JSC::Printer::printCallback):
3618         (JSC::printIndent): Deleted.
3619         (JSC::printCPU): Deleted.
3620         (JSC::printCPURegisters): Deleted.
3621         (JSC::printPC): Deleted.
3622         (JSC::printRegister): Deleted.
3623         (JSC::printMemory): Deleted.
3624         (JSC::MacroAssemblerPrinter::printCallback): Deleted.
3625         * assembler/MacroAssemblerPrinter.h:
3626         (JSC::AllRegisters::AllRegisters):
3627         (JSC::Printer::Printer<AllRegisters>::Printer):
3628         (JSC::Printer::Printer<PCRegister>::Printer):
3629         (JSC::Printer::Printer<MacroAssembler::RegisterID>::Printer):
3630         (JSC::Printer::Printer<MacroAssembler::FPRegisterID>::Printer):
3631         (JSC::Printer::Printer<MacroAssembler::Address>::Printer):
3632         (JSC::Printer::Printer<Memory>::Printer):
3633         (JSC::Printer::Printer<MemWord<IntType>>::Printer):
3634         (JSC::MacroAssembler::print):
3635         (JSC::MacroAssemblerPrinter::print): Deleted.
3636         (JSC::MacroAssemblerPrinter::PrintArg::PrintArg): Deleted.
3637         (JSC::MacroAssemblerPrinter::appendPrintArg): Deleted.
3638         - Refactored to move the underlying PrintRecord (and associated data structures)
3639           out to Printer.cpp/h.
3640         - MacroAssemblerPrinter.cpp/h now only add custom Printers for MASM types like
3641           RegisterID and Memory.  It also defines the implementation of
3642           MacroAssembler::print().
3643
3644           As before, JIT code that wishes to use MacroAssembler::print() needs to
3645           #include "MacroAssemblerPrinter.h".
3646
3647         - Also added the ability to specify an optional indentation (in number of chars)
3648           when MASM printing AllRegisters.  This is useful because AllRegisters prints
3649           a block of data unlike other printers which print inline.
3650
3651         * assembler/Printer.cpp: Added.
3652         (JSC::Printer::printConstCharString):
3653         (JSC::Printer::printIntptr):
3654         (JSC::Printer::printUintptr):
3655         (JSC::Printer::printPointer):
3656         (JSC::Printer::setPrinter):
3657         * assembler/Printer.h: Added.
3658         (JSC::Printer::Context::Context):
3659         (JSC::Printer::PrintRecord::PrintRecord):
3660         (JSC::Printer::appendPrinter):
3661         (JSC::Printer::makePrintRecordList):
3662         (JSC::Printer::Printer<RawPointer>::Printer):
3663         (JSC::Printer::setPrinter):
3664         (JSC::Printer::Printer::Printer):
3665         - Data structures for creating a list of PrintRecords.  Classes which wish to
3666           add custom support for MASM printing can #include "Printer.h" and implement
3667           either:
3668           1. a specialized Printer template, or
3669           2. a setPrinter() function.
3670
3671           See Printer<Reg> and Printer<B3::Air::Tmp> in AirPrintSpecial.h for examples of
3672           (1).  See CodeBlock's setPrinter() for an example of (2).
3673
3674         * b3/B3LowerToAir.cpp:
3675         (JSC::B3::Air::LowerToAir::print):
3676         * b3/air/AirPrintSpecial.cpp: Added.
3677         (JSC::B3::Air::PrintSpecial::PrintSpecial):
3678         (JSC::B3::Air::PrintSpecial::~PrintSpecial):
3679         (JSC::B3::Air::PrintSpecial::forEachArg):
3680         (JSC::B3::Air::PrintSpecial::isValid):
3681         (JSC::B3::Air::PrintSpecial::admitsStack):
3682         (JSC::B3::Air::PrintSpecial::reportUsedRegisters):
3683         (JSC::B3::Air::PrintSpecial::generate):
3684         (JSC::B3::Air::PrintSpecial::extraEarlyClobberedRegs):
3685         (JSC::B3::Air::PrintSpecial::extraClobberedRegs):
3686         (JSC::B3::Air::PrintSpecial::dumpImpl):
3687         (JSC::B3::Air::PrintSpecial::deepDumpImpl):
3688         (JSC::Printer::printAirArg):
3689         * b3/air/AirPrintSpecial.h: Added.
3690         (JSC::Printer::appendAirArg):
3691         (JSC::Printer::appendAirArgs):
3692         (JSC::Printer::Printer<B3::Air::Tmp>::Printer):
3693         (JSC::Printer::Printer<Reg>::Printer):
3694         - Add the print() operation for use in LowerToAir.  print() will emit a
3695           PrintSpecial that will ultimately emit a MASM print to print what we want.
3696         - LowerToAir's print() adds the ability to print Air::Args.
3697         - Unlike in the baseline JIT and the DFG, LowerToAir's print() can perturb the
3698           usage of registers.  This is because PrintSpecial is a patch point, and it
3699           prevents certain optimizations.  If not used carefully, an attempt to print()
3700           an Arg by taking a Tmp, can force the B3 Value into a Tmp earlier than it would
3701           otherwise do so.  So, use LowerToAir's print() with care.
3702
3703         * bytecode/CodeBlock.cpp:
3704         (JSC::setPrinter):
3705         - Now we can MASM print CodeBlock*.
3706         (WTF::printInternal):
3707         - Now we can dataLog CodeBlock* (including null CodeBlock pointers).
3708
3709         * bytecode/CodeBlock.h:
3710
3711         * runtime/VM.cpp:
3712         (JSC::VM::throwException):
3713         - Use the new ability to dataLog CodeBlock*.  No need to do an explicit null
3714           check before printing anymore.
3715
3716 2017-04-21  Keith Miller  <keith_miller@apple.com>
3717
3718         Unreviewed, rolling out r215634.
3719
3720         underlying build issues should have been fixed
3721
3722         Reverted changeset:
3723
3724         "Unreviewed, rolling out r215620 and r215623."
3725         https://bugs.webkit.org/show_bug.cgi?id=171139
3726         http://trac.webkit.org/changeset/215634
3727
3728 2017-04-21  Commit Queue  <commit-queue@webkit.org>
3729
3730         Unreviewed, rolling out r215620 and r215623.
3731         https://bugs.webkit.org/show_bug.cgi?id=171139
3732
3733         broke arm64 build (Requested by keith_miller on #webkit).
3734
3735         Reverted changesets:
3736
3737         "Add signaling API"
3738         https://bugs.webkit.org/show_bug.cgi?id=170976
3739         http://trac.webkit.org/changeset/215620
3740
3741         "Unreviewed, fix Cloop build."
3742         http://trac.webkit.org/changeset/215623
3743
3744 2017-04-21  Keith Miller  <keith_miller@apple.com>
3745
3746         Remove LL/SC from Atomics
3747         https://bugs.webkit.org/show_bug.cgi?id=171141
3748
3749         Reviewed by Saam Barati.
3750
3751         Adding load link and store conditionally was not an actual progression
3752         and the existing code is causing problems for users of Atomics. So let's
3753         get rid of it.
3754
3755         * heap/LargeAllocation.h:
3756         (JSC::LargeAllocation::testAndSetMarked):
3757         * heap/MarkedBlock.h:
3758         (JSC::MarkedBlock::testAndSetMarked):
3759         * heap/SlotVisitor.cpp:
3760         (JSC::SlotVisitor::setMarkedAndAppendToMarkStack):
3761
3762 2017-04-21  Keith Miller  <keith_miller@apple.com>
3763
3764         Unreviewed, fix Cloop build.
3765
3766         * jit/ExecutableAllocator.h:
3767         (JSC::isJITPC):
3768
3769 2017-04-20  Keith Miller  <keith_miller@apple.com>
3770
3771         Add signaling API
3772         https://bugs.webkit.org/show_bug.cgi?id=170976
3773
3774         Reviewed by Filip Pizlo.
3775
3776         Update various uses of sigaction to use the new signaling API.
3777         Also switch VMTraps to use the thread message system instead of
3778         rolling it's own.
3779
3780         * jit/ExecutableAllocator.h:
3781         (JSC::isJITPC):
3782         * runtime/VMTraps.cpp:
3783         (JSC::installSignalHandler):
3784         (JSC::VMTraps::VMTraps):
3785         (JSC::VMTraps::SignalSender::send):
3786         (JSC::handleSigusr1): Deleted.
3787         (JSC::handleSigtrap): Deleted.
3788         (JSC::installSignalHandlers): Deleted.
3789         * runtime/VMTraps.h:
3790         * tools/SigillCrashAnalyzer.cpp:
3791         (JSC::installCrashHandler):
3792         (JSC::handleCrash): Deleted.
3793         * wasm/WasmFaultSignalHandler.cpp:
3794         (JSC::Wasm::trapHandler):
3795         (JSC::Wasm::enableFastMemory):
3796
3797 2017-04-21  Michael Saboff  <msaboff@apple.com>
3798
3799         X86-64 Assembler doesn't handle xchg with byte register src
3800         https://bugs.webkit.org/show_bug.cgi?id=171118
3801
3802         Reviewed by Saam Barati.
3803
3804         * assembler/X86Assembler.h:
3805         (JSC::X86Assembler::xchgb_rm): Use oneByteOp8() since these are 8 bit opcodes.
3806
3807 2017-04-21  Andy VanWagoner  <thetalecrafter@gmail.com>
3808
3809         [INTL] Implement Intl.DateTimeFormat.prototype.formatToParts
3810         https://bugs.webkit.org/show_bug.cgi?id=169458
3811
3812         Reviewed by JF Bastien.
3813
3814         Use udat_formatForFields to iterate through the parts of a formatted date string.
3815         Make formatToParts and related functions dependent on ICU version >= 55.
3816
3817         * icu/unicode/udat.h: Update to 55.1.
3818         * icu/unicode/ufieldpositer.h: Added from 55.1.
3819         * icu/unicode/uvernum.h: Update to 55.1
3820         * runtime/IntlDateTimeFormat.cpp:
3821         (JSC::IntlDateTimeFormat::partTypeString): Convert UDateFormatField to string.
3822         (JSC::IntlDateTimeFormat::formatToParts): Return parts of formatted date string.
3823         * runtime/IntlDateTimeFormat.h:
3824         * runtime/IntlDateTimeFormatPrototype.cpp:
3825         (JSC::IntlDateTimeFormatPrototypeFuncFormatToParts): Add prototype function formatToParts.
3826
3827 2017-04-20  Konstantin Tokarev  <annulen@yandex.ru>
3828
3829         [cmake] Define FORWARDING_HEADERS_DIR in WebKitFS and use it everywhere
3830         https://bugs.webkit.org/show_bug.cgi?id=171071
3831
3832         Reviewed by Michael Catanzaro.
3833
3834         "${DERIVED_SOURCES_DIR}/ForwardingHeaders" path occurs very often in the
3835         build system files. GTK-specifc FORWARDING_HEADERS_DIR variable should
3836         be available for all ports.
3837
3838         * CMakeLists.txt:
3839         * PlatformWin.cmake:
3840
3841 2017-04-20  Konstantin Tokarev  <annulen@yandex.ru>
3842
3843         Remove unused lamda captures
3844         https://bugs.webkit.org/show_bug.cgi?id=171098
3845
3846         Reviewed by Yusuke Suzuki.
3847
3848         * bytecompiler/NodesCodegen.cpp:
3849         (JSC::ArrayNode::emitBytecode):
3850         * ftl/FTLState.cpp:
3851         (JSC::FTL::State::State):
3852         * wasm/WasmB3IRGenerator.cpp:
3853
3854 2017-04-20  Yusuke Suzuki  <utatane.tea@gmail.com>
3855
3856         [JSC][FTL] FTL should support Arrayify
3857         https://bugs.webkit.org/show_bug.cgi?id=169596
3858
3859         Reviewed by Saam Barati.
3860
3861         This patch simply expands the coverage of FTL by supporting Arrayify.
3862         While ArrayifyToStructure is already supported, Arrayify is not supported
3863         in FTL. While supporting Arrayify in FTL itself does not offer so much
3864         performance difference from DFG's one, no FTL support for Arrayify
3865         prevents us applying FTL to the code including Arrayify.
3866
3867         * dfg/DFGArrayMode.cpp:
3868         (JSC::DFG::toIndexingShape):
3869         * dfg/DFGSpeculativeJIT.cpp:
3870         (JSC::DFG::SpeculativeJIT::jumpSlowForUnwantedArrayMode):
3871         * ftl/FTLCapabilities.cpp:
3872         (JSC::FTL::canCompile):
3873         * ftl/FTLLowerDFGToB3.cpp:
3874         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
3875         (JSC::FTL::DFG::LowerDFGToB3::compileArrayify):
3876         (JSC::FTL::DFG::LowerDFGToB3::compileCheckArray):
3877         (JSC::FTL::DFG::LowerDFGToB3::isArrayTypeForArrayify):
3878         (JSC::FTL::DFG::LowerDFGToB3::isArrayTypeForCheckArray):
3879         (JSC::FTL::DFG::LowerDFGToB3::compileArrayifyToStructure): Deleted.
3880         (JSC::FTL::DFG::LowerDFGToB3::isArrayType): Deleted.
3881
3882 2017-04-20  Mark Lam  <mark.lam@apple.com>
3883
3884         virtualThunkFor() needs to materialize its of tagMaskRegister for tail calls.
3885         https://bugs.webkit.org/show_bug.cgi?id=171079
3886         <rdar://problem/31684756>
3887
3888         Reviewed by Saam Barati.
3889
3890         This is needed because tail calls would restore callee saved registers (and
3891         therefore, potentially clobber the tag registers) before jumping to the thunk.
3892
3893         * jit/ThunkGenerators.cpp:
3894         (JSC::virtualThunkFor):
3895
3896 2017-04-20  Mark Lam  <mark.lam@apple.com>
3897
3898         Build fix after r215592.
3899         https://bugs.webkit.org/show_bug.cgi?id=171088
3900
3901         Not reviewed.
3902
3903         * assembler/MacroAssemblerPrinter.h:
3904
3905 2017-04-20  Mark Lam  <mark.lam@apple.com>
3906
3907         Update the MASM probe to only take 1 arg instead of 2 (in addition to the callback function).
3908         https://bugs.webkit.org/show_bug.cgi?id=171088
3909
3910         Reviewed by Michael Saboff and Saam Barati.
3911
3912         Experience shows that we never use the 2nd arg.  So, let's remove it to reduce
3913         the footprint at each probe site.
3914
3915         Also fix the MacroAssembler::print() function so that it is a no-op when
3916         !ENABLE(MASM_PROBE).  This will allow us to have print() statements in JIT code
3917         without a lot of #if ENABLE(MASM_PROBE)s later.
3918
3919         * assembler/AbstractMacroAssembler.h:
3920         * assembler/MacroAssembler.cpp:
3921         (JSC::stdFunctionCallback):
3922         (JSC::MacroAssembler::probe):
3923         * assembler/MacroAssembler.h:
3924         * assembler/MacroAssemblerARM.cpp:
3925         (JSC::MacroAssemblerARM::probe):
3926         * assembler/MacroAssemblerARM.h:
3927         * assembler/MacroAssemblerARM64.cpp:
3928         (JSC::MacroAssemblerARM64::probe):
3929         * assembler/MacroAssemblerARM64.h:
3930         * assembler/MacroAssemblerARMv7.cpp:
3931         (JSC::MacroAssemblerARMv7::probe):
3932         * assembler/MacroAssemblerARMv7.h:
3933         * assembler/MacroAssemblerPrinter.cpp:
3934         (JSC::MacroAssemblerPrinter::printCallback):
3935         * assembler/MacroAssemblerPrinter.h:
3936         (JSC::MacroAssemblerPrinter::print):
3937         (JSC::MacroAssembler::print):
3938         * assembler/MacroAssemblerX86Common.cpp:
3939         (JSC::MacroAssemblerX86Common::probe):
3940         * assembler/MacroAssemblerX86Common.h:
3941
3942 2017-04-20  Matt Baker  <mattbaker@apple.com>
3943
3944         Web Inspector: Add regular expression support to XHR breakpoints
3945         https://bugs.webkit.org/show_bug.cgi?id=170099
3946         <rdar://problem/31558082>
3947
3948         Reviewed by Joseph Pecoraro.
3949
3950         * inspector/protocol/DOMDebugger.json:
3951         New optional `isRegex` parameter denotes whether `url` contains
3952         a regular expression.
3953
3954 2017-04-15  Filip Pizlo  <fpizlo@apple.com>
3955
3956         Optimize SharedArrayBuffer in the DFG+FTL
3957         https://bugs.webkit.org/show_bug.cgi?id=164108
3958
3959         Reviewed by Saam Barati.
3960         
3961         This adds atomics intrinsics to the DFG