WebAssembly: perform stack checks
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2017-05-18  Saam Barati  <sbarati@apple.com>
2
3         WebAssembly: perform stack checks
4         https://bugs.webkit.org/show_bug.cgi?id=165546
5         <rdar://problem/29760307>
6
7         Reviewed by Filip Pizlo.
8
9         This patch adds stack checks to wasm. It implements it by storing the stack
10         bounds on the Context.
11         
12         Stack checking works as normal, except we do a small optimization for terminal
13         nodes in the call tree (nodes that don't make any calls). These nodes will
14         only do a stack check if their frame size is beyond 1024 bytes. Otherwise,
15         it's assumed the parent that called them did their stack check for them.
16         This is because all things that make calls make sure to do an extra 1024
17         bytes whenever doing a stack check.
18         
19         We also take into account stack size for potential JS calls when doing
20         stack checks since our JS stubs don't do this on their own. Each frame
21         will ensure it does a stack check large enough for any potential JS call
22         stubs it'll execute.
23         
24         Surprisingly, this patch is neutral on WasmBench and TitzerBench.
25
26         * llint/LLIntData.cpp:
27         (JSC::LLInt::Data::performAssertions):
28         * llint/LowLevelInterpreter.asm:
29         * runtime/Error.cpp:
30         (JSC::createRangeError):
31         (JSC::addErrorInfoAndGetBytecodeOffset):
32         I fixed a bug here where we assumed that the first frame that has line
33         and column info would be in our stack trace. This is not correct
34         since we limit our stack trace size. If everything in our limited
35         size stack trace is Wasm, then we won't have any frames with line
36         and column info.
37         * runtime/Error.h:
38         * runtime/ExceptionHelpers.cpp:
39         (JSC::createStackOverflowError):
40         * runtime/ExceptionHelpers.h:
41         * runtime/JSGlobalObject.cpp:
42         (JSC::JSGlobalObject::init):
43         (JSC::JSGlobalObject::visitChildren):
44         * runtime/JSGlobalObject.h:
45         (JSC::JSGlobalObject::webAssemblyToJSCalleeStructure):
46         * runtime/JSType.h:
47         * runtime/Options.h: I've added a new option that controls
48         whether or not we use fast TLS for the wasm context.
49         * runtime/VM.cpp:
50         (JSC::VM::VM):
51         * runtime/VM.h:
52         * wasm/WasmB3IRGenerator.cpp:
53         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
54         * wasm/WasmBinding.cpp:
55         (JSC::Wasm::wasmToWasm):
56         * wasm/WasmContext.cpp:
57         (JSC::Wasm::loadContext):
58         (JSC::Wasm::storeContext):
59         * wasm/WasmContext.h:
60         (JSC::Wasm::useFastTLSForContext):
61         * wasm/WasmExceptionType.h:
62         * wasm/WasmMemoryInformation.h:
63         (JSC::Wasm::PinnedRegisterInfo::toSave):
64         * wasm/WasmThunks.cpp:
65         (JSC::Wasm::throwExceptionFromWasmThunkGenerator):
66         (JSC::Wasm::throwStackOverflowFromWasmThunkGenerator):
67         (JSC::Wasm::Thunks::stub):
68         * wasm/WasmThunks.h:
69         * wasm/js/JSWebAssemblyInstance.h:
70         (JSC::JSWebAssemblyInstance::offsetOfCachedStackLimit):
71         (JSC::JSWebAssemblyInstance::cachedStackLimit):
72         (JSC::JSWebAssemblyInstance::setCachedStackLimit):
73         * wasm/js/JSWebAssemblyModule.cpp:
74         (JSC::JSWebAssemblyModule::finishCreation):
75         * wasm/js/WebAssemblyFunction.cpp:
76         (JSC::callWebAssemblyFunction):
77         * wasm/js/WebAssemblyToJSCallee.cpp: Make this a descendent of object.
78         This is needed for correctness because we may call into JS,
79         and then the first JS frame could stack overflow. When it stack
80         overflows, it rolls back one frame to the wasm->js call stub with
81         the wasm->js callee. It gets the lexical global object from this
82         frame, meaning it gets the global object from the callee. Therefore,
83         we must make it an object since all objects have global objects.
84         (JSC::WebAssemblyToJSCallee::create):
85         * wasm/js/WebAssemblyToJSCallee.h:
86
87 2017-05-18  Keith Miller  <keith_miller@apple.com>
88
89         WebAssembly API: test with neutered inputs
90         https://bugs.webkit.org/show_bug.cgi?id=163899
91
92         Reviewed by JF Bastien.
93
94         Add tests to check that we properly throw a type error when
95         we get a transferred ArrayBuffer. Also, we should make sure
96         we cannot post message a wasm memory's ArrayBuffer.
97
98         * API/JSTypedArray.cpp:
99         (JSObjectGetArrayBufferBytesPtr):
100         * runtime/ArrayBuffer.cpp:
101         (JSC::ArrayBuffer::makeShared):
102         (JSC::ArrayBuffer::makeWasmMemory):
103         (JSC::ArrayBuffer::transferTo):
104         (JSC::ArrayBuffer::neuter):
105         (JSC::ArrayBuffer::notifyIncommingReferencesOfTransfer):
106         (JSC::errorMesasgeForTransfer):
107         * runtime/ArrayBuffer.h:
108         (JSC::ArrayBuffer::isLocked):
109         (JSC::ArrayBuffer::isWasmMemory):
110         * wasm/js/JSWebAssemblyMemory.cpp:
111         (JSC::JSWebAssemblyMemory::buffer):
112         (JSC::JSWebAssemblyMemory::grow):
113
114 2017-05-18  Joseph Pecoraro  <pecoraro@apple.com>
115
116         Remote Inspector: Be stricter about checking message types
117         https://bugs.webkit.org/show_bug.cgi?id=172259
118         <rdar://problem/32264839>
119
120         Reviewed by Brian Burg.
121
122         * inspector/remote/cocoa/RemoteInspectorCocoa.mm:
123         (Inspector::RemoteInspector::receivedSetupMessage):
124         (Inspector::RemoteInspector::receivedDataMessage):
125         (Inspector::RemoteInspector::receivedDidCloseMessage):
126         (Inspector::RemoteInspector::receivedIndicateMessage):
127         (Inspector::RemoteInspector::receivedConnectionDiedMessage):
128         (Inspector::RemoteInspector::receivedAutomaticInspectionConfigurationMessage):
129         (Inspector::RemoteInspector::receivedAutomaticInspectionRejectMessage):
130         (Inspector::RemoteInspector::receivedAutomationSessionRequestMessage):
131         * inspector/remote/cocoa/RemoteInspectorXPCConnection.mm:
132         (Inspector::RemoteInspectorXPCConnection::deserializeMessage):
133         (Inspector::RemoteInspectorXPCConnection::handleEvent):
134         (Inspector::RemoteInspectorXPCConnection::sendMessage):
135         Bail if we don't receive the expected types for message data.
136
137 2017-05-18  Filip Pizlo  <fpizlo@apple.com>
138
139         DFG inlining should be hardened for the no-result case
140         https://bugs.webkit.org/show_bug.cgi?id=172290
141
142         Reviewed by Saam Barati.
143         
144         Previously, if we were inlining a setter call, we might have a bad time because the setter's
145         result register is the invalid VirtualRegister(), and much of the intrinsic handling code
146         assumes that the result register is valid.
147         
148         This doesn't usually cause problems because people don't usually point a setter at something
149         that we recognize as an intrinsic.
150         
151         * CMakeLists.txt:
152         * JavaScriptCore.xcodeproj/project.pbxproj:
153         * b3/air/AirAllocateRegistersAndStackByLinearScan.cpp: Fix a comment.
154         * dfg/DFGByteCodeParser.cpp: Make RELEASE_ASSERT give accurate stacks. I was getting an absurd stack from the assert I added in DelayedSetLocal.
155         (JSC::DFG::ByteCodeParser::DelayedSetLocal::DelayedSetLocal): Assert so we catch the problem sooner.
156         (JSC::DFG::ByteCodeParser::handleIntrinsicCall): Fix the bug.
157         (JSC::DFG::ByteCodeParser::handleConstantInternalFunction): Fix the bug if constant internal functions were setter-inlineable (they ain't, because the bytecode parser doesn't fold GetSetter).
158         * runtime/Intrinsic.cpp: Added. I needed this to debug.
159         (JSC::intrinsicName):
160         (WTF::printInternal):
161         * runtime/Intrinsic.h:
162
163 2017-05-18  Commit Queue  <commit-queue@webkit.org>
164
165         Unreviewed, rolling out r217031, r217032, and r217037.
166         https://bugs.webkit.org/show_bug.cgi?id=172293
167
168         cause linking errors in Windows (Requested by yusukesuzuki on
169         #webkit).
170
171         Reverted changesets:
172
173         "[JSC][DFG][DOMJIT] Extend CheckDOM to CheckSubClass"
174         https://bugs.webkit.org/show_bug.cgi?id=172098
175         http://trac.webkit.org/changeset/217031
176
177         "Unreviewed, rebaseline for newly added ClassInfo"
178         https://bugs.webkit.org/show_bug.cgi?id=172098
179         http://trac.webkit.org/changeset/217032
180
181         "Unreviewed, fix debug and non-JIT build"
182         https://bugs.webkit.org/show_bug.cgi?id=172098
183         http://trac.webkit.org/changeset/217037
184
185 2017-05-17  Yusuke Suzuki  <utatane.tea@gmail.com>
186
187         Unreviewed, fix debug and non-JIT build
188         https://bugs.webkit.org/show_bug.cgi?id=172098
189
190         * jsc.cpp:
191         (WTF::DOMJITFunctionObject::checkSubClassPatchpoint):
192
193 2017-05-17  Yusuke Suzuki  <utatane.tea@gmail.com>
194
195         Unreviewed, rebaseline for newly added ClassInfo
196         https://bugs.webkit.org/show_bug.cgi?id=172098
197
198         * wasm/js/WebAssemblyFunctionBase.cpp:
199
200 2017-05-16  Yusuke Suzuki  <utatane.tea@gmail.com>
201
202         [JSC][DFG][DOMJIT] Extend CheckDOM to CheckSubClass
203         https://bugs.webkit.org/show_bug.cgi?id=172098
204
205         Reviewed by Saam Barati.
206
207         In this patch, we generalize CheckDOM to CheckSubClass.
208         It can accept any ClassInfo and perform ClassInfo check
209         in DFG / FTL. Now, we add a new function pointer to ClassInfo,
210         checkSubClassPatchpoint. It can create DOMJIT patchpoint
211         for that ClassInfo. It it natural that ClassInfo holds the
212         way to emit DOMJIT::Patchpoint to perform CheckSubClass
213         rather than having it in each DOMJIT getter / function
214         signature annotation.
215
216         One problem is that it enlarges the size of ClassInfo.
217         But this is the best place to put this function pointer.
218         By doing so, we can add a patchpoint for CheckSubClass
219         in an non-intrusive manner: WebCore can inject patchpoints
220         without interactive JSC.
221
222         We still have a way to reduce the size of ClassInfo if
223         we move ArrayBuffer related methods out to the other places.
224
225         This patch touches many files because we add a new function
226         pointer to ClassInfo. But they are basically mechanical change.
227
228         * API/JSAPIWrapperObject.mm:
229         * API/JSCallbackConstructor.cpp:
230         * API/JSCallbackFunction.cpp:
231         * API/JSCallbackObject.cpp:
232         * API/ObjCCallbackFunction.mm:
233         * CMakeLists.txt:
234         * JavaScriptCore.xcodeproj/project.pbxproj:
235         * bytecode/CodeBlock.cpp:
236         * bytecode/DOMJITAccessCasePatchpointParams.h:
237         (JSC::DOMJITAccessCasePatchpointParams::DOMJITAccessCasePatchpointParams):
238         * bytecode/EvalCodeBlock.cpp:
239         * bytecode/FunctionCodeBlock.cpp:
240         * bytecode/GetterSetterAccessCase.cpp:
241         (JSC::GetterSetterAccessCase::emitDOMJITGetter):
242         * bytecode/ModuleProgramCodeBlock.cpp:
243         * bytecode/ProgramCodeBlock.cpp:
244         * bytecode/UnlinkedCodeBlock.cpp:
245         * bytecode/UnlinkedEvalCodeBlock.cpp:
246         * bytecode/UnlinkedFunctionCodeBlock.cpp:
247         * bytecode/UnlinkedFunctionExecutable.cpp:
248         * bytecode/UnlinkedModuleProgramCodeBlock.cpp:
249         * bytecode/UnlinkedProgramCodeBlock.cpp:
250         * debugger/DebuggerScope.cpp:
251         * dfg/DFGAbstractInterpreterInlines.h:
252         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
253         * dfg/DFGByteCodeParser.cpp:
254         (JSC::DFG::ByteCodeParser::handleDOMJITGetter):
255         * dfg/DFGClobberize.h:
256         (JSC::DFG::clobberize):
257         * dfg/DFGConstantFoldingPhase.cpp:
258         (JSC::DFG::ConstantFoldingPhase::foldConstants):
259         * dfg/DFGDOMJITPatchpointParams.h:
260         (JSC::DFG::DOMJITPatchpointParams::DOMJITPatchpointParams):
261         * dfg/DFGDoesGC.cpp:
262         (JSC::DFG::doesGC):
263         * dfg/DFGFixupPhase.cpp:
264         (JSC::DFG::FixupPhase::fixupNode):
265         (JSC::DFG::FixupPhase::attemptToMakeCallDOM):
266         (JSC::DFG::FixupPhase::fixupCheckSubClass):
267         (JSC::DFG::FixupPhase::fixupCheckDOM): Deleted.
268         * dfg/DFGGraph.cpp:
269         (JSC::DFG::Graph::dump):
270         * dfg/DFGNode.h:
271         (JSC::DFG::Node::hasClassInfo):
272         (JSC::DFG::Node::classInfo):
273         (JSC::DFG::Node::hasCheckDOMPatchpoint): Deleted.
274         (JSC::DFG::Node::checkDOMPatchpoint): Deleted.
275         * dfg/DFGNodeType.h:
276         * dfg/DFGPredictionPropagationPhase.cpp:
277         * dfg/DFGSafeToExecute.h:
278         (JSC::DFG::safeToExecute):
279         * dfg/DFGSpeculativeJIT.cpp:
280         (JSC::DFG::SpeculativeJIT::compileCheckSubClass):
281         (JSC::DFG::SpeculativeJIT::compileCheckDOM): Deleted.
282         * dfg/DFGSpeculativeJIT.h:
283         (JSC::DFG::SpeculativeJIT::vm):
284         * dfg/DFGSpeculativeJIT32_64.cpp:
285         (JSC::DFG::SpeculativeJIT::compile):
286         In DFG, we rename CheckDOM to CheckSubClass. It just holds ClassInfo.
287         And ClassInfo knows how to perform CheckSubClass efficiently.
288         If ClassInfo does not have a way to perform CheckSubClass efficiently,
289         we just perform jsDynamicCast thing in ASM.
290         * dfg/DFGSpeculativeJIT64.cpp:
291         (JSC::DFG::SpeculativeJIT::compile):
292         * domjit/DOMJITGetterSetter.h:
293         * domjit/DOMJITPatchpointParams.h:
294         (JSC::DOMJIT::PatchpointParams::PatchpointParams):
295         (JSC::DOMJIT::PatchpointParams::vm):
296         * domjit/DOMJITSignature.h:
297         (JSC::DOMJIT::Signature::Signature):
298         (JSC::DOMJIT::Signature::checkDOM): Deleted.
299         * ftl/FTLAbstractHeapRepository.h:
300         * ftl/FTLCapabilities.cpp:
301         (JSC::FTL::canCompile):
302         * ftl/FTLDOMJITPatchpointParams.h:
303         (JSC::FTL::DOMJITPatchpointParams::DOMJITPatchpointParams):
304         * ftl/FTLLowerDFGToB3.cpp:
305         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
306         (JSC::FTL::DFG::LowerDFGToB3::compileCheckSubClass):
307         (JSC::FTL::DFG::LowerDFGToB3::compileCheckDOM): Deleted.
308         * inspector/JSInjectedScriptHost.cpp:
309         * inspector/JSInjectedScriptHostPrototype.cpp:
310         * inspector/JSJavaScriptCallFrame.cpp:
311         * inspector/JSJavaScriptCallFramePrototype.cpp:
312         * jsc.cpp:
313         (WTF::DOMJITNode::checkSubClassPatchpoint):
314         (WTF::DOMJITFunctionObject::checkSubClassPatchpoint):
315         (WTF::DOMJITFunctionObject::finishCreation):
316         (WTF::DOMJITCheckSubClassObject::DOMJITCheckSubClassObject):
317         (WTF::DOMJITCheckSubClassObject::createStructure):
318         (WTF::DOMJITCheckSubClassObject::create):
319         (WTF::DOMJITCheckSubClassObject::safeFunction):
320         (WTF::DOMJITCheckSubClassObject::unsafeFunction):
321         (WTF::DOMJITCheckSubClassObject::finishCreation):
322         (GlobalObject::finishCreation):
323         (functionCreateDOMJITCheckSubClassObject):
324         (WTF::DOMJITNode::checkDOMJITNode): Deleted.
325         (WTF::DOMJITFunctionObject::checkDOMJITNode): Deleted.
326         * runtime/AbstractModuleRecord.cpp:
327         * runtime/ArrayBufferNeuteringWatchpoint.cpp:
328         * runtime/ArrayConstructor.cpp:
329         * runtime/ArrayIteratorPrototype.cpp:
330         * runtime/ArrayPrototype.cpp:
331         * runtime/AsyncFunctionConstructor.cpp:
332         * runtime/AsyncFunctionPrototype.cpp:
333         * runtime/AtomicsObject.cpp:
334         * runtime/BooleanConstructor.cpp:
335         * runtime/BooleanObject.cpp:
336         * runtime/BooleanPrototype.cpp:
337         * runtime/ClassInfo.cpp: Copied from Source/JavaScriptCore/tools/JSDollarVM.cpp.
338         (JSC::ClassInfo::dump):
339         * runtime/ClassInfo.h:
340         (JSC::ClassInfo::offsetOfParentClass):
341         * runtime/ClonedArguments.cpp:
342         * runtime/ConsoleObject.cpp:
343         * runtime/CustomGetterSetter.cpp:
344         * runtime/DateConstructor.cpp:
345         * runtime/DateInstance.cpp:
346         * runtime/DatePrototype.cpp:
347         * runtime/DirectArguments.cpp:
348         * runtime/Error.cpp:
349         * runtime/ErrorConstructor.cpp:
350         * runtime/ErrorInstance.cpp:
351         * runtime/ErrorPrototype.cpp:
352         * runtime/EvalExecutable.cpp:
353         * runtime/Exception.cpp:
354         * runtime/ExceptionHelpers.cpp:
355         * runtime/ExecutableBase.cpp:
356         * runtime/FunctionConstructor.cpp:
357         * runtime/FunctionExecutable.cpp:
358         * runtime/FunctionPrototype.cpp:
359         * runtime/FunctionRareData.cpp:
360         * runtime/GeneratorFunctionConstructor.cpp:
361         * runtime/GeneratorFunctionPrototype.cpp:
362         * runtime/GeneratorPrototype.cpp:
363         * runtime/GetterSetter.cpp:
364         * runtime/HashMapImpl.cpp:
365         * runtime/HashMapImpl.h:
366         * runtime/InferredType.cpp:
367         (JSC::InferredType::create):
368         * runtime/InferredTypeTable.cpp:
369         * runtime/InferredValue.cpp:
370         * runtime/InspectorInstrumentationObject.cpp:
371         * runtime/InternalFunction.cpp:
372         * runtime/IntlCollator.cpp:
373         * runtime/IntlCollatorConstructor.cpp:
374         * runtime/IntlCollatorPrototype.cpp:
375         * runtime/IntlDateTimeFormat.cpp:
376         * runtime/IntlDateTimeFormatConstructor.cpp:
377         * runtime/IntlDateTimeFormatPrototype.cpp:
378         * runtime/IntlNumberFormat.cpp:
379         * runtime/IntlNumberFormatConstructor.cpp:
380         * runtime/IntlNumberFormatPrototype.cpp:
381         * runtime/IntlObject.cpp:
382         * runtime/IteratorPrototype.cpp:
383         * runtime/JSAPIValueWrapper.cpp:
384         * runtime/JSArray.cpp:
385         * runtime/JSArrayBuffer.cpp:
386         * runtime/JSArrayBufferConstructor.cpp:
387         * runtime/JSArrayBufferPrototype.cpp:
388         * runtime/JSArrayBufferView.cpp:
389         * runtime/JSAsyncFunction.cpp:
390         * runtime/JSBoundFunction.cpp:
391         * runtime/JSCallee.cpp:
392         * runtime/JSCustomGetterSetterFunction.cpp:
393         * runtime/JSDataView.cpp:
394         * runtime/JSDataViewPrototype.cpp:
395         * runtime/JSEnvironmentRecord.cpp:
396         * runtime/JSFixedArray.cpp:
397         * runtime/JSFunction.cpp:
398         * runtime/JSGeneratorFunction.cpp:
399         * runtime/JSGlobalLexicalEnvironment.cpp:
400         * runtime/JSGlobalObject.cpp:
401         * runtime/JSInternalPromise.cpp:
402         * runtime/JSInternalPromiseConstructor.cpp:
403         * runtime/JSInternalPromiseDeferred.cpp:
404         * runtime/JSInternalPromisePrototype.cpp:
405         * runtime/JSLexicalEnvironment.cpp:
406         * runtime/JSMap.cpp:
407         * runtime/JSMapIterator.cpp:
408         * runtime/JSModuleEnvironment.cpp:
409         * runtime/JSModuleLoader.cpp:
410         * runtime/JSModuleNamespaceObject.cpp:
411         * runtime/JSModuleRecord.cpp:
412         * runtime/JSNativeStdFunction.cpp:
413         * runtime/JSONObject.cpp:
414         * runtime/JSObject.cpp:
415         * runtime/JSPromise.cpp:
416         * runtime/JSPromiseConstructor.cpp:
417         * runtime/JSPromiseDeferred.cpp:
418         * runtime/JSPromisePrototype.cpp:
419         * runtime/JSPropertyNameEnumerator.cpp:
420         * runtime/JSPropertyNameIterator.cpp:
421         * runtime/JSProxy.cpp:
422         * runtime/JSScriptFetcher.cpp:
423         * runtime/JSSet.cpp:
424         * runtime/JSSetIterator.cpp:
425         * runtime/JSSourceCode.cpp:
426         * runtime/JSString.cpp:
427         * runtime/JSStringIterator.cpp:
428         * runtime/JSSymbolTableObject.cpp:
429         * runtime/JSTemplateRegistryKey.cpp:
430         * runtime/JSTypedArrayConstructors.cpp:
431         * runtime/JSTypedArrayPrototypes.cpp:
432         * runtime/JSTypedArrayViewConstructor.cpp:
433         * runtime/JSTypedArrays.cpp:
434         * runtime/JSWeakMap.cpp:
435         * runtime/JSWeakSet.cpp:
436         * runtime/JSWithScope.cpp:
437         * runtime/MapConstructor.cpp:
438         * runtime/MapIteratorPrototype.cpp:
439         * runtime/MapPrototype.cpp:
440         * runtime/MathObject.cpp:
441         * runtime/ModuleLoaderPrototype.cpp:
442         * runtime/ModuleProgramExecutable.cpp:
443         * runtime/NativeErrorConstructor.cpp:
444         * runtime/NativeExecutable.cpp:
445         * runtime/NativeStdFunctionCell.cpp:
446         * runtime/NullGetterFunction.cpp:
447         * runtime/NullSetterFunction.cpp:
448         * runtime/NumberConstructor.cpp:
449         * runtime/NumberObject.cpp:
450         * runtime/NumberPrototype.cpp:
451         * runtime/ObjectConstructor.cpp:
452         * runtime/ObjectPrototype.cpp:
453         * runtime/ProgramExecutable.cpp:
454         * runtime/PropertyTable.cpp:
455         * runtime/ProxyConstructor.cpp:
456         * runtime/ProxyObject.cpp:
457         * runtime/ProxyRevoke.cpp:
458         * runtime/ReflectObject.cpp:
459         * runtime/RegExp.cpp:
460         * runtime/RegExpConstructor.cpp:
461         * runtime/RegExpObject.cpp:
462         * runtime/RegExpPrototype.cpp:
463         * runtime/ScopedArguments.cpp:
464         * runtime/ScopedArgumentsTable.cpp:
465         * runtime/ScriptExecutable.cpp:
466         * runtime/SetConstructor.cpp:
467         * runtime/SetIteratorPrototype.cpp:
468         * runtime/SetPrototype.cpp:
469         * runtime/SparseArrayValueMap.cpp:
470         * runtime/StrictEvalActivation.cpp:
471         * runtime/StringConstructor.cpp:
472         * runtime/StringIteratorPrototype.cpp:
473         * runtime/StringObject.cpp:
474         * runtime/StringPrototype.cpp:
475         * runtime/Structure.cpp:
476         * runtime/StructureChain.cpp:
477         * runtime/StructureRareData.cpp:
478         * runtime/Symbol.cpp:
479         * runtime/SymbolConstructor.cpp:
480         * runtime/SymbolObject.cpp:
481         * runtime/SymbolPrototype.cpp:
482         * runtime/SymbolTable.cpp:
483         * runtime/WeakMapConstructor.cpp:
484         * runtime/WeakMapData.cpp:
485         * runtime/WeakMapPrototype.cpp:
486         * runtime/WeakSetConstructor.cpp:
487         * runtime/WeakSetPrototype.cpp:
488         * testRegExp.cpp:
489         * tools/JSDollarVM.cpp:
490         * tools/JSDollarVMPrototype.cpp:
491         * wasm/JSWebAssembly.cpp:
492         * wasm/js/JSWebAssemblyCodeBlock.cpp:
493         * wasm/js/JSWebAssemblyCompileError.cpp:
494         * wasm/js/JSWebAssemblyInstance.cpp:
495         * wasm/js/JSWebAssemblyLinkError.cpp:
496         * wasm/js/JSWebAssemblyMemory.cpp:
497         * wasm/js/JSWebAssemblyModule.cpp:
498         * wasm/js/JSWebAssemblyRuntimeError.cpp:
499         * wasm/js/JSWebAssemblyTable.cpp:
500         * wasm/js/WebAssemblyCompileErrorConstructor.cpp:
501         * wasm/js/WebAssemblyCompileErrorPrototype.cpp:
502         * wasm/js/WebAssemblyFunction.cpp:
503         * wasm/js/WebAssemblyInstanceConstructor.cpp:
504         * wasm/js/WebAssemblyInstancePrototype.cpp:
505         * wasm/js/WebAssemblyLinkErrorConstructor.cpp:
506         * wasm/js/WebAssemblyLinkErrorPrototype.cpp:
507         * wasm/js/WebAssemblyMemoryConstructor.cpp:
508         * wasm/js/WebAssemblyMemoryPrototype.cpp:
509         * wasm/js/WebAssemblyModuleConstructor.cpp:
510         * wasm/js/WebAssemblyModulePrototype.cpp:
511         * wasm/js/WebAssemblyModuleRecord.cpp:
512         * wasm/js/WebAssemblyPrototype.cpp:
513         * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
514         * wasm/js/WebAssemblyRuntimeErrorPrototype.cpp:
515         * wasm/js/WebAssemblyTableConstructor.cpp:
516         * wasm/js/WebAssemblyTablePrototype.cpp:
517         * wasm/js/WebAssemblyToJSCallee.cpp:
518         * wasm/js/WebAssemblyWrapperFunction.cpp:
519
520 2017-05-17  Saam Barati  <sbarati@apple.com>
521
522         We don't do context switches for Wasm->Wasm call indirect
523         https://bugs.webkit.org/show_bug.cgi?id=172188
524         <rdar://problem/32231828>
525
526         Reviewed by Keith Miller.
527
528         We did not do a context switch when doing an indirect call. 
529         This is clearly wrong, since the thing we're making an indirect
530         call to could be from another instance. This patch fixes this
531         oversight by doing a very simple context switch. I've also opened
532         a bug to make indirect calls fast: https://bugs.webkit.org/show_bug.cgi?id=172197
533         since this patch adds yet another branch to the indirect call path.
534         I've also added tests that either throw or crash before this change.
535
536         * CMakeLists.txt:
537         * JavaScriptCore.xcodeproj/project.pbxproj:
538         * wasm/WasmB3IRGenerator.cpp:
539         * wasm/js/JSWebAssemblyTable.h:
540         (JSC::JSWebAssemblyTable::offsetOfJSFunctions):
541         * wasm/js/WebAssemblyFunction.cpp:
542         (JSC::WebAssemblyFunction::visitChildren):
543         (JSC::WebAssemblyFunction::finishCreation): Deleted.
544         * wasm/js/WebAssemblyFunction.h:
545         (JSC::WebAssemblyFunction::instance): Deleted.
546         (JSC::WebAssemblyFunction::offsetOfInstance): Deleted.
547         * wasm/js/WebAssemblyFunctionBase.cpp: Added.
548         (JSC::WebAssemblyFunctionBase::WebAssemblyFunctionBase):
549         (JSC::WebAssemblyFunctionBase::visitChildren):
550         (JSC::WebAssemblyFunctionBase::finishCreation):
551         * wasm/js/WebAssemblyFunctionBase.h: Added.
552         (JSC::WebAssemblyFunctionBase::instance):
553         (JSC::WebAssemblyFunctionBase::offsetOfInstance):
554         * wasm/js/WebAssemblyModuleRecord.cpp:
555         (JSC::WebAssemblyModuleRecord::link):
556         (JSC::WebAssemblyModuleRecord::evaluate):
557         * wasm/js/WebAssemblyWrapperFunction.cpp:
558         (JSC::WebAssemblyWrapperFunction::create):
559         (JSC::WebAssemblyWrapperFunction::finishCreation):
560         (JSC::WebAssemblyWrapperFunction::visitChildren):
561         * wasm/js/WebAssemblyWrapperFunction.h:
562
563 2017-05-17  Filip Pizlo  <fpizlo@apple.com>
564
565         JSC: Incorrect LoadVarargs handling in ArgumentsEliminationPhase::transform
566         https://bugs.webkit.org/show_bug.cgi?id=172208
567
568         Reviewed by Saam Barati.
569
570         * dfg/DFGArgumentsEliminationPhase.cpp:
571
572 2017-05-17  Don Olmstead  <don.olmstead@am.sony.com>
573
574         [Win] Support $vm.getpid()
575         https://bugs.webkit.org/show_bug.cgi?id=172248
576
577         Reviewed by Mark Lam.
578
579         * tools/JSDollarVMPrototype.cpp:
580         (JSC::functionGetPID):
581         (JSC::JSDollarVMPrototype::finishCreation):
582
583 2017-05-17  Michael Saboff  <msaboff@apple.com>
584
585         [iOS] The Garbage Collector shouldn't rely on the bmalloc scavenger for up to date memory footprint info
586         https://bugs.webkit.org/show_bug.cgi?id=172186
587
588         Reviewed by Geoffrey Garen.
589
590         The calls to bmalloc::api::memoryFootprint() and ::percentAvailableMemoryInUse() now call
591         the OS to get up to date values.  In overCriticalMemoryThreshold(), we get the current value every
592         100th call and use a cached value the rest of the time.  When colleciton is done, we start with
593         a new overCriticalMemoryThreshold value for the next cycle.
594
595         The choice of 1 out of 100 calls was validated by using JetStream and verifying that it didn't impact
596         performance and still provides timely memory footprint data.  With additional debug logging, I
597         determined that we call overCriticalMemoryThreshold() over 20,000 times/second running JetStream.
598         Other logging showed that there were over 1700 calls to overCriticalMemoryThreshold() on average per
599         GC cycle.  Dividing both of these numbers by 100 seems reasonable.
600
601         * heap/Heap.cpp:
602         (JSC::Heap::overCriticalMemoryThreshold):
603         (JSC::Heap::updateAllocationLimits):
604         (JSC::Heap::shouldDoFullCollection):
605         * heap/Heap.h:
606
607 2017-05-17  Saam Barati  <sbarati@apple.com>
608
609         PinnedRegisters should be better modeled in IRC/Briggs
610         https://bugs.webkit.org/show_bug.cgi?id=171955
611
612         Reviewed by Filip Pizlo.
613
614         This patch fixes a bug in Briggs/IRC with respect to pinned registers.
615         Pinned registers were not part of the assignable register file in IRC/Briggs,
616         and this would lead to an asymmetry because they were modeled in the
617         interference graph. The bug is that we use registerCount() to move various
618         Tmps between various lists in the different allocators, and if a Tmp
619         interfered with a pinned register (usually via a Patchpoint's clobbered set),
620         we'd have an interference edge modeled in the degree for that Tmp, but the registerCount()
621         would make us think that this particular Tmp is not assignable. This would
622         lead us to fail to color a colorable graph. Specifically, this happened in
623         our various patchpoint tests that stress the register allocator by forcing
624         the entire register file into arguments for the patchpoint and then doing
625         interesting things with the result, arguments, etc.
626         
627         This patch fixes the bug by coming up with an more natural way to model pinned
628         registers. Pinned registers are now part of the register file. However,
629         pinned registers are live at every point in the program (this is a defining
630         property of a pinned register). In practice, this means that the only Tmps 
631         that can be assigned to pinned registers are ones that are coalescing
632         candidates. This means the program has some number of defs for a Tmp T like:
633         MoveType pinnedReg, T
634         
635         Note, if any other defs for T happen, like:
636         Add32, t1, t2, T
637         T will have an interference edge with pinnedReg, since pinnedReg is live
638         at every point in the program. Modeling pinned registers this way allows
639         IRC/Briggs to have no special casing for them. It treats it like any other
640         precolored Tmp. This allows us to do coalescing, biased coloring, etc, which
641         could all lead to a Tmp being assigned to a pinned register.
642         
643         Interestingly, we used to have special handling for the frame pointer
644         register, which in many ways, acts like a pinned register, since FP is
645         always live, and we wanted it to take place in coalescing. The allocator
646         had a side-table interference graph with FP. Interestingly, we didn't even
647         handle this properly everywhere since we could rely on a patchpoint never
648         claiming to clobber FP (this would be illegal). So the code only handled
649         the pseudo-pinned register properties of FP in various places. This patch
650         drops this special casing and pins FP since all pinned registers can take
651         part in coalescing.
652
653         * b3/B3PatchpointSpecial.h:
654         * b3/B3Procedure.cpp:
655         (JSC::B3::Procedure::mutableGPRs):
656         (JSC::B3::Procedure::mutableFPRs):
657         * b3/B3Procedure.h:
658         * b3/air/AirAllocateRegistersByGraphColoring.cpp:
659         * b3/air/AirCode.cpp:
660         (JSC::B3::Air::Code::Code):
661         (JSC::B3::Air::Code::pinRegister):
662         (JSC::B3::Air::Code::mutableGPRs):
663         (JSC::B3::Air::Code::mutableFPRs):
664         * b3/air/AirCode.h:
665         (JSC::B3::Air::Code::pinnedRegisters):
666         * b3/air/AirSpecial.h:
667         * b3/air/testair.cpp:
668         * b3/testb3.cpp:
669         (JSC::B3::testSimplePatchpointWithOuputClobbersGPArgs):
670         (JSC::B3::testSpillDefSmallerThanUse):
671         (JSC::B3::testLateRegister):
672         (JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled):
673         (JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled2):
674         (JSC::B3::testMoveConstants):
675
676 2017-05-16  Yusuke Suzuki  <utatane.tea@gmail.com>
677
678         [DFG] Constant Folding Phase should convert MakeRope("", String) => Identity(String)
679         https://bugs.webkit.org/show_bug.cgi?id=172115
680
681         Reviewed by Saam Barati.
682
683         In Fixup phase, we attempt to fold MakeRope to Identity (or reduce arguments) by dropping
684         empty strings. However, when we are in Fixup phase, we do not have much information about
685         constant values.
686
687         In ARES-6 Babylon, we find that we can constant-fold MakeRope by using constants figured
688         out by CFA. Without it, Babylon repeatedly produces rope strings. To fix this, we introduce
689         MakeRope handling in constant folding phase.
690
691         It shows 7.5% performance improvement in ARES-6 Babylon steadyState.
692
693             Before:
694
695             firstIteration:     50.02 +- 14.56 ms
696             averageWorstCase:   26.52 +- 4.52 ms
697             steadyState:        8.15 +- 0.23 ms
698
699             After:
700
701             firstIteration:     49.08 +- 12.90 ms
702             averageWorstCase:   25.16 +- 3.82 ms
703             steadyState:        7.58 +- 0.21 ms
704
705         * dfg/DFGAbstractInterpreterInlines.h:
706         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
707         * dfg/DFGConstantFoldingPhase.cpp:
708         (JSC::DFG::ConstantFoldingPhase::foldConstants):
709
710 2017-05-16  Yusuke Suzuki  <utatane.tea@gmail.com>
711
712         Unreviewed, add Objective C files to CMake Mac port
713         https://bugs.webkit.org/show_bug.cgi?id=172103
714
715         * shell/PlatformMac.cmake: Added.
716
717 2017-05-16  JF Bastien  <jfbastien@apple.com>
718
719         WebAssembly: enforce size limits
720         https://bugs.webkit.org/show_bug.cgi?id=165833
721         <rdar://problem/29760219>
722
723         Reviewed by Keith Miller.
724
725         Use the same limits as V8.
726
727         * JavaScriptCore.xcodeproj/project.pbxproj:
728         * wasm/WasmLimits.h: Added.
729         * wasm/WasmModuleParser.cpp:
730         * wasm/WasmParser.h:
731         (JSC::Wasm::Parser<SuccessType>::consumeUTF8String):
732
733 2017-05-15  Yusuke Suzuki  <utatane.tea@gmail.com>
734
735         [JSC] Build testapi in non Apple ports
736         https://bugs.webkit.org/show_bug.cgi?id=172103
737
738         Reviewed by Filip Pizlo.
739
740         This patch makes JSC testapi buildable in non-Apple ports.
741         We isolate CF related tests in testapi.c. If we do not use
742         CF, we include JavaScript.h instead of JavaScriptCore.h.
743
744         By running the testapi in Linux, we found that contraints
745         test have a bug: If constraint marker runs after WeakRefs
746         are destroyed, it accesses destroyed WeakRef. This patch
747         also fixes it.
748
749         * API/tests/CurrentThisInsideBlockGetterTest.h:
750         * API/tests/CustomGlobalObjectClassTest.c:
751         * API/tests/ExecutionTimeLimitTest.cpp:
752         * API/tests/FunctionOverridesTest.cpp:
753         * API/tests/GlobalContextWithFinalizerTest.cpp:
754         * API/tests/JSObjectGetProxyTargetTest.cpp:
755         * API/tests/MultithreadedMultiVMExecutionTest.cpp:
756         * API/tests/PingPongStackOverflowTest.cpp:
757         * API/tests/TypedArrayCTest.cpp:
758         * API/tests/testapi.c:
759         (assertEqualsAsCharactersPtr):
760         (markingConstraint):
761         (testMarkingConstraintsAndHeapFinalizers):
762         (testCFStrings):
763         (main):
764         * shell/CMakeLists.txt:
765
766 2017-05-16  JF Bastien  <jfbastien@apple.com>
767
768         WebAssembly: report Memory usage to GC
769         https://bugs.webkit.org/show_bug.cgi?id=170690
770         <rdar://problem/31965310>
771
772         Reviewed by Keith Miller.
773
774         * wasm/js/JSWebAssemblyMemory.cpp:
775         (JSC::JSWebAssemblyMemory::grow):
776         (JSC::JSWebAssemblyMemory::finishCreation):
777         (JSC::JSWebAssemblyMemory::visitChildren):
778
779 2017-05-16  JF Bastien  <jfbastien@apple.com>
780
781         WebAssembly: validate load / store alignment
782         https://bugs.webkit.org/show_bug.cgi?id=168836
783         <rdar://problem/31965349>
784
785         Reviewed by Keith Miller.
786
787         * wasm/WasmFunctionParser.h: check the alignment
788         * wasm/generateWasm.py: generate the log2 alignment helper
789         (Wasm):
790         (isSimple):
791         (memoryLog2Alignment):
792         * wasm/generateWasmOpsHeader.py:
793         (memoryLog2AlignmentGenerator):
794         * wasm/wasm.json: fix formatting
795
796 2017-05-15  Mark Lam  <mark.lam@apple.com>
797
798         Rolling out r214038 and r213697: Crashes when using computed properties with rest destructuring and object spread.
799         https://bugs.webkit.org/show_bug.cgi?id=172147
800
801         Rubber-stamped by Saam Barati.
802
803         I rolled out every thing in those 2 patches except for the change to make
804         CodeBlock::finishCreation() return a bool plus its clients that depend on this.
805         I made this exception because r214931 relies on this change, and this part of
806         the change looks correct.
807
808         * builtins/BuiltinNames.h:
809         * builtins/GlobalOperations.js:
810         (globalPrivate.speciesConstructor):
811         (globalPrivate.copyDataProperties): Deleted.
812         * bytecode/CodeBlock.cpp:
813         (JSC::CodeBlock::finishCreation):
814         (JSC::CodeBlock::setConstantIdentifierSetRegisters): Deleted.
815         * bytecode/CodeBlock.h:
816         * bytecode/UnlinkedCodeBlock.h:
817         (JSC::UnlinkedCodeBlock::addBitVector):
818         (JSC::UnlinkedCodeBlock::constantRegisters):
819         (JSC::UnlinkedCodeBlock::addSetConstant): Deleted.
820         (JSC::UnlinkedCodeBlock::constantIdentifierSets): Deleted.
821         * bytecompiler/BytecodeGenerator.cpp:
822         * bytecompiler/BytecodeGenerator.h:
823         * bytecompiler/NodesCodegen.cpp:
824         (JSC::PropertyListNode::emitBytecode):
825         (JSC::ObjectPatternNode::bindValue):
826         (JSC::ObjectSpreadExpressionNode::emitBytecode): Deleted.
827         * parser/ASTBuilder.h:
828         (JSC::ASTBuilder::createProperty):
829         (JSC::ASTBuilder::appendObjectPatternEntry):
830         (JSC::ASTBuilder::createObjectSpreadExpression): Deleted.
831         (JSC::ASTBuilder::appendObjectPatternRestEntry): Deleted.
832         (JSC::ASTBuilder::setContainsObjectRestElement): Deleted.
833         * parser/NodeConstructors.h:
834         (JSC::PropertyNode::PropertyNode):
835         (JSC::SpreadExpressionNode::SpreadExpressionNode):
836         (JSC::ObjectSpreadExpressionNode::ObjectSpreadExpressionNode): Deleted.
837         * parser/Nodes.h:
838         (JSC::ObjectPatternNode::appendEntry):
839         (JSC::ObjectSpreadExpressionNode::expression): Deleted.
840         (JSC::ObjectPatternNode::setContainsRestElement): Deleted.
841         * parser/Parser.cpp:
842         (JSC::Parser<LexerType>::parseDestructuringPattern):
843         (JSC::Parser<LexerType>::parseProperty):
844         * parser/SyntaxChecker.h:
845         (JSC::SyntaxChecker::createSpreadExpression):
846         (JSC::SyntaxChecker::createProperty):
847         (JSC::SyntaxChecker::operatorStackPop):
848         (JSC::SyntaxChecker::createObjectSpreadExpression): Deleted.
849         * runtime/ObjectConstructor.cpp:
850         (JSC::ObjectConstructor::finishCreation):
851         * runtime/SetPrototype.cpp:
852         (JSC::SetPrototype::finishCreation):
853
854 2017-05-15  David Kilzer  <ddkilzer@apple.com>
855
856         JSEnvironmentRecord::allocationSizeForScopeSize() and offsetOfVariable(ScopeOffset) should used checked arithmetic
857         <https://webkit.org/b/172134>
858
859         Reviewed by Saam Barati.
860
861         * runtime/JSEnvironmentRecord.h:
862         (JSC::JSEnvironmentRecord::offsetOfVariable): Change to return
863         size_t and use checked arithmetic.
864         (JSC::JSEnvironmentRecord::allocationSizeForScopeSize): Change
865         to use checked arithmetic.
866
867 2017-05-15  Mark Lam  <mark.lam@apple.com>
868
869         WorkerRunLoop::Task::performTask() should check !scriptController->isTerminatingExecution().
870         https://bugs.webkit.org/show_bug.cgi?id=171775
871         <rdar://problem/30975761>
872
873         Reviewed by Filip Pizlo.
874
875         Increased the number of frames captured in VM::nativeStackTraceOfLastThrow()
876         from 25 to 100.  From experience, I found that 25 is sometimes not sufficient
877         for our debugging needs.
878
879         Also added VM::throwingThread() to track which thread an exception was thrown in.
880         This may be useful if the client is entering the VM from different threads.
881
882         * runtime/ExceptionScope.cpp:
883         (JSC::ExceptionScope::unexpectedExceptionMessage):
884         * runtime/ExceptionScope.h:
885         (JSC::ExceptionScope::exception):
886         (JSC::ExceptionScope::unexpectedExceptionMessage):
887         * runtime/Options.h:
888         - Added the unexpectedExceptionStackTraceLimit option.
889         * runtime/VM.cpp:
890         (JSC::VM::throwException):
891         * runtime/VM.h:
892         (JSC::VM::throwingThread):
893         (JSC::VM::clearException):
894
895 2017-05-13  David Kilzer  <ddkilzer@apple.com>
896
897         Unused lambda capture in JSContextGroupAddMarkingConstraint()
898         <https://webkit.org/b/172084>
899
900         Reviewed by Saam Barati.
901
902         Fixes the following warning with newer clang:
903
904             Source/JavaScriptCore/API/JSMarkingConstraintPrivate.cpp:78:11: error: lambda capture 'vm' is not used [-Werror,-Wunused-lambda-capture]
905                     [&vm, constraintCallback, userData]
906                       ^
907
908         * API/JSMarkingConstraintPrivate.cpp:
909         (JSContextGroupAddMarkingConstraint): Remove unused lambda
910         capture for '&vm'.
911
912 2017-05-13  David Kilzer  <ddkilzer@apple.com>
913
914         [JSC] config.rb fails when checking some clang versions
915         <https://webkit.org/b/172082>
916
917         Reviewed by Mark Lam.
918
919         * offlineasm/config.rb:
920         - Add support for quad-dotted version of Apple clang (800.0.12.1).
921         - Add support for checking open source clang version (5.0.0).
922
923 2017-05-13  Commit Queue  <commit-queue@webkit.org>
924
925         Unreviewed, rolling out r216808.
926         https://bugs.webkit.org/show_bug.cgi?id=172075
927
928         caused lldb to hang when debugging (Requested by smfr on
929         #webkit).
930
931         Reverted changeset:
932
933         "Use Mach exceptions instead of signals where possible"
934         https://bugs.webkit.org/show_bug.cgi?id=171865
935         http://trac.webkit.org/changeset/216808
936
937 2017-05-13  Commit Queue  <commit-queue@webkit.org>
938
939         Unreviewed, rolling out r216801.
940         https://bugs.webkit.org/show_bug.cgi?id=172072
941
942         Many memory corruption crashes on worker threads (Requested by
943         ap on #webkit).
944
945         Reverted changeset:
946
947         "WorkerRunLoop::Task::performTask() should check
948         !scriptController->isTerminatingExecution()."
949         https://bugs.webkit.org/show_bug.cgi?id=171775
950         http://trac.webkit.org/changeset/216801
951
952 2017-05-12  Geoffrey Garen  <ggaren@apple.com>
953
954         [JSC] DFG::Node should not have its own allocator
955         https://bugs.webkit.org/show_bug.cgi?id=160098
956
957         Reviewed by Saam Barati.
958
959         I just rebased the patch from <http://trac.webkit.org/changeset/203808>.
960
961         I ran Octane and JetStream locally on a MacBook Air and I wasn't able to
962         reproduce a regression. Let's land this again and see what the bots say.
963
964         * JavaScriptCore.xcodeproj/project.pbxproj:
965         * b3/B3SparseCollection.h:
966         (JSC::B3::SparseCollection::packIndices):
967         * dfg/DFGAllocator.h: Removed.
968         * dfg/DFGDriver.cpp:
969         (JSC::DFG::compileImpl):
970         * dfg/DFGGraph.cpp:
971         (JSC::DFG::Graph::Graph):
972         (JSC::DFG::Graph::~Graph):
973         (JSC::DFG::Graph::deleteNode):
974         (JSC::DFG::Graph::packNodeIndices):
975         (JSC::DFG::Graph::addNodeToMapByIndex): Deleted.
976         * dfg/DFGGraph.h:
977         (JSC::DFG::Graph::addNode):
978         (JSC::DFG::Graph::maxNodeCount):
979         (JSC::DFG::Graph::nodeAt):
980         * dfg/DFGLongLivedState.cpp: Removed.
981         * dfg/DFGLongLivedState.h: Removed.
982         * dfg/DFGNode.h:
983         * dfg/DFGNodeAllocator.h:
984         * dfg/DFGPlan.cpp:
985         (JSC::DFG::Plan::compileInThread):
986         (JSC::DFG::Plan::compileInThreadImpl):
987         * dfg/DFGPlan.h:
988         * dfg/DFGWorklist.cpp:
989         * runtime/VM.cpp:
990         (JSC::VM::VM):
991         * runtime/VM.h:
992
993 2017-05-12  Keith Miller  <keith_miller@apple.com>
994
995         Use Mach exceptions instead of signals where possible
996         https://bugs.webkit.org/show_bug.cgi?id=171865
997
998         Reviewed by Mark Lam.
999
1000         This patch adds some new JSC options. The first is an option that
1001         enables or disables web assembly tier up. The second controls
1002         whether or not we use mach exceptions (where available).
1003
1004         * API/tests/ExecutionTimeLimitTest.cpp:
1005         (dispatchTermitateCallback):
1006         (testExecutionTimeLimit):
1007         * runtime/JSLock.cpp:
1008         (JSC::JSLock::didAcquireLock):
1009         * runtime/Options.cpp:
1010         (JSC::overrideDefaults):
1011         (JSC::Options::initialize):
1012         * runtime/Options.h:
1013         * runtime/VMTraps.cpp:
1014         (JSC::SignalContext::SignalContext):
1015         (JSC::SignalContext::adjustPCToPointToTrappingInstruction):
1016         (JSC::installSignalHandler):
1017         (JSC::VMTraps::SignalSender::send):
1018         * tools/SigillCrashAnalyzer.cpp:
1019         (JSC::SignalContext::SignalContext):
1020         (JSC::SignalContext::dump):
1021         (JSC::installCrashHandler):
1022         * wasm/WasmBBQPlan.cpp:
1023         (JSC::Wasm::BBQPlan::compileFunctions):
1024         * wasm/WasmFaultSignalHandler.cpp:
1025         (JSC::Wasm::trapHandler):
1026         (JSC::Wasm::enableFastMemory):
1027         * wasm/WasmMachineThreads.cpp:
1028         (JSC::Wasm::resetInstructionCacheOnAllThreads):
1029
1030 2017-05-12  Mark Lam  <mark.lam@apple.com>
1031
1032         WorkerRunLoop::Task::performTask() should check !scriptController->isTerminatingExecution().
1033         https://bugs.webkit.org/show_bug.cgi?id=171775
1034         <rdar://problem/30975761>
1035
1036         Reviewed by Saam Barati.
1037
1038         Increased the number of frames captured in VM::nativeStackTraceOfLastThrow()
1039         from 25 to 100.  From experience, I found that 25 is sometimes not sufficient
1040         for our debugging needs.
1041
1042         Also added VM::throwingThread() to track which thread an exception was thrown in.
1043         This may be useful if the client is entering the VM from different threads.
1044
1045         * runtime/ExceptionScope.cpp:
1046         (JSC::ExceptionScope::unexpectedExceptionMessage):
1047         * runtime/ExceptionScope.h:
1048         (JSC::ExceptionScope::exception):
1049         (JSC::ExceptionScope::unexpectedExceptionMessage):
1050         * runtime/Options.h:
1051         - Added the unexpectedExceptionStackTraceLimit option.
1052         * runtime/VM.cpp:
1053         (JSC::VM::throwException):
1054         * runtime/VM.h:
1055         (JSC::VM::throwingThread):
1056         (JSC::VM::clearException):
1057
1058 2017-05-12  Daniel Bates  <dabates@apple.com>
1059
1060         Cleanup: Make QueueTaskToEventLoopFunctionPtr take JSGlobalObject&
1061         https://bugs.webkit.org/show_bug.cgi?id=172021
1062
1063         Reviewed by Mark Lam.
1064
1065         Change the function alias for QueueTaskToEventLoopFunctionPtr to take JSGlobalObject&
1066         instead of a const JSGlobalObject* as all implementations expect to be passed a non-
1067         const, non-null JSGlobalObject object.
1068
1069         * runtime/JSGlobalObject.cpp:
1070         (JSC::JSGlobalObject::queueMicrotask):
1071         * runtime/JSGlobalObject.h:
1072         * runtime/VM.cpp:
1073         (JSC::VM::queueMicrotask):
1074         * runtime/VM.h: Remove JS_EXPORT_PRIVATE annotation from queueMicrotask() as
1075         it is only called from JavaScriptCore code.
1076
1077 2017-05-12  Michael Saboff  <msaboff@apple.com>
1078
1079         [iOS] Use memory footprint to dynamically adjust behavior of allocators
1080         https://bugs.webkit.org/show_bug.cgi?id=171944
1081
1082         Reviewed by Filip Pizlo.
1083
1084         This change is iOS only.
1085
1086         Added the ability to react to when memory usage is critical.  This is defined as memory
1087         usage being above the newly added option criticalGCMemoryThreshold.  When we are in this
1088         critical state, all collections are Full and we limit the amount of memory we allocate
1089         between collections to 1/4th the memory above the critical threshold.
1090
1091         Changed the calculation of proportionalHeapSize to be based on process memory footprint
1092         and not how big the heap is.  Also, the values of Options::smallHeapRAMFraction and
1093         Options::mediumHeapRAMFraction are overriden so that most of the heap growth is happens
1094         using the more agressive Options::smallHeapGrowthFactor.
1095
1096         * heap/Heap.cpp:
1097         (JSC::Heap::Heap):
1098         (JSC::Heap::overCriticalMemoryThreshold):
1099         (JSC::Heap::shouldDoFullCollection):
1100         (JSC::Heap::collectIfNecessaryOrDefer):
1101         * heap/Heap.h:
1102         * runtime/Options.cpp:
1103         (JSC::overrideDefaults):
1104         (JSC::Options::initialize):
1105         * runtime/Options.h:
1106
1107 2017-05-11  Saam Barati  <sbarati@apple.com>
1108
1109         Computing optionalDefArgWidth in CheckSpecial should not consider Scratch roles
1110         https://bugs.webkit.org/show_bug.cgi?id=171962
1111
1112         Reviewed by Filip Pizlo.
1113
1114         The purpose of getting the result width is to get the width of
1115         the result of the arithmetic. It does not care about that the
1116         Check happens to define scratches.
1117
1118         * b3/B3CheckSpecial.cpp:
1119         (JSC::B3::CheckSpecial::forEachArg):
1120         * b3/testb3.cpp:
1121         (JSC::B3::testCheckMul):
1122         (JSC::B3::testCheckMulMemory):
1123         (JSC::B3::testCheckMul64):
1124         (JSC::B3::testCheckMulFold):
1125         (JSC::B3::testCheckMulFoldFail):
1126         (JSC::B3::testCheckMulArgumentAliasing64):
1127         (JSC::B3::testCheckMulArgumentAliasing32):
1128         (JSC::B3::testCheckMul64SShr):
1129
1130 2017-05-11  Saam Barati  <sbarati@apple.com>
1131
1132         isValidForm for SimpleAddr should use ptr() instead of tmp()
1133         https://bugs.webkit.org/show_bug.cgi?id=171992
1134
1135         Reviewed by Filip Pizlo.
1136
1137         Arg::tmp() asserts that its kind is Tmp. Inst::isValidForm for
1138         SimpleAddr was using Arg::tmp() instead of ptr() to check
1139         if the address Tmp isGP(). It should be using Arg::ptr() instead
1140         of Arg::tmp() since Arg::ptr() is designed for SimpleAddr.
1141         
1142         This patch also fixes an incorrect assertion in the ARM64
1143         macro assembler. We were asserting various atomic ops were
1144         only over 32/64 bit operations. However, the code was properly handling
1145         8/16/32/64 bit ops. I changed the assertion to reflect what is
1146         actually going on.
1147
1148         * assembler/ARM64Assembler.h:
1149         (JSC::ARM64Assembler::ldar):
1150         (JSC::ARM64Assembler::ldxr):
1151         (JSC::ARM64Assembler::ldaxr):
1152         (JSC::ARM64Assembler::stxr):
1153         (JSC::ARM64Assembler::stlr):
1154         (JSC::ARM64Assembler::stlxr):
1155         * b3/air/opcode_generator.rb:
1156         * b3/testb3.cpp:
1157         (JSC::B3::testLoadAcq42):
1158         (JSC::B3::testStoreRelAddLoadAcq32):
1159         (JSC::B3::testStoreRelAddLoadAcq8):
1160         (JSC::B3::testStoreRelAddFenceLoadAcq8):
1161         (JSC::B3::testStoreRelAddLoadAcq16):
1162         (JSC::B3::testStoreRelAddLoadAcq64):
1163         (JSC::B3::testAtomicWeakCAS):
1164         (JSC::B3::testAtomicStrongCAS):
1165         (JSC::B3::testAtomicXchg):
1166
1167 2017-05-11  Matt Lewis  <jlewis3@apple.com>
1168
1169         Unreviewed, rolling out r216677.
1170
1171         Patch caused layout test crashes.
1172
1173         Reverted changeset:
1174
1175         "WorkerThread::stop() should call
1176         scheduleExecutionTermination() last."
1177         https://bugs.webkit.org/show_bug.cgi?id=171775
1178         http://trac.webkit.org/changeset/216677
1179
1180 2017-05-11  Don Olmstead  <don.olmstead@am.sony.com>
1181
1182         [CMake] Add HAVE check for regex.h
1183         https://bugs.webkit.org/show_bug.cgi?id=171950
1184
1185         Reviewed by Michael Catanzaro.
1186
1187         * runtime/ConfigFile.cpp:
1188         (JSC::ConfigFile::parse):
1189
1190 2017-05-11  Filip Pizlo  <fpizlo@apple.com>
1191
1192         Callers of JSString::unsafeView() should check exceptions
1193         https://bugs.webkit.org/show_bug.cgi?id=171995
1194
1195         Reviewed by Mark Lam.
1196         
1197         unsafeView() can throw OOME. So, callers of unsafeView() should check for exceptions before trying
1198         to access the view.
1199
1200         Also, I made the functions surrounding unsafeView() take ExecState* not ExecState&, to comply with
1201         the rest of JSC.
1202
1203         * dfg/DFGOperations.cpp:
1204         * jsc.cpp:
1205         (printInternal):
1206         (functionDebug):
1207         * runtime/ArrayPrototype.cpp:
1208         (JSC::arrayProtoFuncJoin):
1209         * runtime/FunctionConstructor.cpp:
1210         (JSC::constructFunctionSkippingEvalEnabledCheck):
1211         * runtime/IntlCollatorPrototype.cpp:
1212         (JSC::IntlCollatorFuncCompare):
1213         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
1214         (JSC::genericTypedArrayViewProtoFuncJoin):
1215         * runtime/JSGlobalObjectFunctions.cpp:
1216         (JSC::globalFuncParseFloat):
1217         * runtime/JSONObject.cpp:
1218         (JSC::JSONProtoFuncParse):
1219         * runtime/JSString.cpp:
1220         (JSC::JSString::getPrimitiveNumber):
1221         (JSC::JSString::toNumber):
1222         * runtime/JSString.h:
1223         (JSC::JSString::getIndex):
1224         (JSC::JSRopeString::unsafeView):
1225         (JSC::JSRopeString::viewWithUnderlyingString):
1226         (JSC::JSString::unsafeView):
1227         (JSC::JSString::viewWithUnderlyingString):
1228         * runtime/JSStringJoiner.h:
1229         (JSC::JSStringJoiner::appendWithoutSideEffects):
1230         (JSC::JSStringJoiner::append):
1231         * runtime/ParseInt.h:
1232         (JSC::toStringView):
1233         * runtime/StringPrototype.cpp:
1234         (JSC::stringProtoFuncRepeatCharacter):
1235         (JSC::stringProtoFuncCharAt):
1236         (JSC::stringProtoFuncCharCodeAt):
1237         (JSC::stringProtoFuncIndexOf):
1238         (JSC::stringProtoFuncNormalize):
1239
1240 2017-05-11  Filip Pizlo  <fpizlo@apple.com>
1241
1242         Offer SPI to notify clients that GC has happened
1243         https://bugs.webkit.org/show_bug.cgi?id=171980
1244
1245         Reviewed by Geoffrey Garen.
1246         
1247         Sometimes when you're programming with weak references, it's most convenient if the GC tells
1248         you when it finishes. This adds exactly such an API. This API is called at the *flip*: the
1249         moment when the GC knows for sure which objects are dead and has definitely not allocated any
1250         new objects or executed any JS code. The finalization part of the flip, which is where this
1251         callback gets called, runs on the "main" thread - i.e. some thread that is attempting to
1252         execute JS code and holds the JS lock. This will usually run as a side-effect of some
1253         allocation or from the runloop.
1254         
1255         This means, for example, that if you implemented a vector of weak references and registered a
1256         callback to prune the vector of null weak references, then aside from the callback, nobody
1257         would ever see a null weak reference in the vector.
1258
1259         * API/JSHeapFinalizerPrivate.cpp: Added.
1260         (JSContextGroupAddHeapFinalizer):
1261         (JSContextGroupRemoveHeapFinalizer):
1262         * API/JSHeapFinalizerPrivate.h: Added.
1263         * API/tests/testapi.c:
1264         (heapFinalizer):
1265         (testMarkingConstraintsAndHeapFinalizers):
1266         (main):
1267         (testMarkingConstraints): Deleted.
1268         * CMakeLists.txt:
1269         * JavaScriptCore.xcodeproj/project.pbxproj:
1270         * heap/Heap.cpp:
1271         (JSC::Heap::finalize):
1272         (JSC::Heap::addHeapFinalizerCallback):
1273         (JSC::Heap::removeHeapFinalizerCallback):
1274         * heap/Heap.h:
1275         * heap/HeapFinalizerCallback.cpp: Added.
1276         (JSC::HeapFinalizerCallback::dump):
1277         * heap/HeapFinalizerCallback.h: Added.
1278         (JSC::HeapFinalizerCallback::HeapFinalizerCallback):
1279         (JSC::HeapFinalizerCallback::operator==):
1280         (JSC::HeapFinalizerCallback::operator!=):
1281         (JSC::HeapFinalizerCallback::operator bool):
1282         (JSC::HeapFinalizerCallback::run):
1283
1284 2017-05-11  Filip Pizlo  <fpizlo@apple.com>
1285
1286         JSWeakCreate/Retain/Release should take a JSContextGroupRef and not a JSContextRef
1287         https://bugs.webkit.org/show_bug.cgi?id=171979
1288
1289         Reviewed by Mark Lam.
1290         
1291         Functions that don't execute arbitrary JS but just need access to the VM should take a
1292         JSContextGroupRef, not a JSContextRef.
1293
1294         * API/JSWeakPrivate.cpp:
1295         (JSWeakCreate):
1296         (JSWeakRetain):
1297         (JSWeakRelease):
1298         * API/JSWeakPrivate.h:
1299         * API/tests/testapi.c:
1300         (testMarkingConstraints):
1301
1302 2017-05-11  Mark Lam  <mark.lam@apple.com>
1303
1304         WorkerThread::stop() should call scheduleExecutionTermination() last.
1305         https://bugs.webkit.org/show_bug.cgi?id=171775
1306         <rdar://problem/30975761>
1307
1308         Reviewed by Geoffrey Garen.
1309
1310         Increased the number of frames captured in VM::nativeStackTraceOfLastThrow()
1311         from 25 to 100.  From experience, I found that 25 is sometimes not sufficient
1312         for our debugging needs.
1313
1314         Also added VM::throwingThread() to track which thread an exception was thrown in.
1315         This may be useful if the client is entering the VM from different threads.
1316
1317         * runtime/ExceptionScope.cpp:
1318         (JSC::ExceptionScope::unexpectedExceptionMessage):
1319         (JSC::ExceptionScope::releaseAssertIsTerminatedExecutionException):
1320         * runtime/ExceptionScope.h:
1321         (JSC::ExceptionScope::exception):
1322         (JSC::ExceptionScope::unexpectedExceptionMessage):
1323         * runtime/VM.cpp:
1324         (JSC::VM::throwException):
1325         * runtime/VM.h:
1326         (JSC::VM::throwingThread):
1327         (JSC::VM::clearException):
1328
1329 2017-05-11  JF Bastien  <jfbastien@apple.com>
1330
1331         WebAssembly: stop supporting 0xD
1332         https://bugs.webkit.org/show_bug.cgi?id=168788
1333         <rdar://problem/31880922>
1334
1335         Reviewed by Saam Barati.
1336
1337         Only version 1 is supported by other browsers, and there shouldn't
1338         be any 0xD binaries in the wild anymore.
1339
1340         * wasm/WasmModuleParser.cpp:
1341
1342 2017-05-09  Sam Weinig  <sam@webkit.org>
1343
1344         Remove support for legacy Notifications
1345         https://bugs.webkit.org/show_bug.cgi?id=171487
1346
1347         Reviewed by Jon Lee.
1348
1349         * Configurations/FeatureDefines.xcconfig:
1350         Remove definition of ENABLE_LEGACY_NOTIFICATIONS.
1351
1352 2017-05-10  Commit Queue  <commit-queue@webkit.org>
1353
1354         Unreviewed, rolling out r216635.
1355         https://bugs.webkit.org/show_bug.cgi?id=171953
1356
1357         "Some worker tests are failing". (Requested by mlam on #webkit).
1358
1359         Reverted changeset:
1360
1361         "WorkerThread::stop() should call
1362         scheduleExecutionTermination() last."
1363         https://bugs.webkit.org/show_bug.cgi?id=171775
1364         http://trac.webkit.org/changeset/216635
1365
1366 2017-05-10  Mark Lam  <mark.lam@apple.com>
1367
1368         Crash in JavaScriptCore GC when using JSC on dispatch queues (thread_get_state returns NULL stack pointer).
1369         https://bugs.webkit.org/show_bug.cgi?id=160337
1370         <rdar://problem/27611733>
1371
1372         Not reviewed.
1373
1374         Updated a comment per Geoff's suggestion.
1375
1376         * heap/MachineStackMarker.cpp:
1377         (JSC::MachineThreads::tryCopyOtherThreadStack):
1378
1379 2017-05-10  Mark Lam  <mark.lam@apple.com>
1380
1381         WorkerThread::stop() should call scheduleExecutionTermination() last.
1382         https://bugs.webkit.org/show_bug.cgi?id=171775
1383         <rdar://problem/30975761>
1384
1385         Reviewed by Geoffrey Garen.
1386
1387         Increased the number of frames captured in VM::nativeStackTraceOfLastThrow()
1388         from 25 to 100.  From experience, I found that 25 is sometimes not sufficient
1389         for our debugging needs.
1390
1391         Also added VM::throwingThread() to track which thread an exception was thrown in.
1392         This may be useful if the client is entering the VM from different threads.
1393
1394         * runtime/ExceptionScope.cpp:
1395         (JSC::ExceptionScope::unexpectedExceptionMessage):
1396         (JSC::ExceptionScope::releaseAssertIsTerminatedExecutionException):
1397         * runtime/ExceptionScope.h:
1398         (JSC::ExceptionScope::exception):
1399         (JSC::ExceptionScope::unexpectedExceptionMessage):
1400         * runtime/VM.cpp:
1401         (JSC::VM::throwException):
1402         * runtime/VM.h:
1403         (JSC::VM::throwingThread):
1404         (JSC::VM::clearException):
1405
1406 2017-05-10  Mark Lam  <mark.lam@apple.com>
1407
1408         Crash in JavaScriptCore GC when using JSC on dispatch queues (thread_get_state returns NULL stack pointer).
1409         https://bugs.webkit.org/show_bug.cgi?id=160337
1410         <rdar://problem/27611733>
1411
1412         Reviewed by Filip Pizlo and Geoffrey Garen.
1413
1414         This is a workaround for <rdar://problem/27607384>. During thread initialization,
1415         for some target platforms, thread state is momentarily set to 0 before being
1416         filled in with the target thread's real register values. As a result, there's
1417         a race condition that may result in us getting a null stackPointer during a GC scan.
1418         This issue may manifest with workqueue threads where the OS may choose to recycle
1419         a thread for an expired task.
1420
1421         The workaround is simply to indicate that there's nothing to copy and return.
1422         This is correct because we will only ever observe a null pointer during thread
1423         initialization. Hence, by definition, there's nothing there that we need to scan
1424         yet, and therefore, nothing that needs to be copied.
1425
1426         * heap/MachineStackMarker.cpp:
1427         (JSC::MachineThreads::tryCopyOtherThreadStack):
1428
1429 2017-05-10  JF Bastien  <jfbastien@apple.com>
1430
1431         WebAssembly: support name section
1432
1433         https://bugs.webkit.org/show_bug.cgi?id=171263
1434
1435         Reviewed by Keith Miller.
1436
1437         The name section is an optional custom section in the WebAssembly
1438         spec. At least when debugging, developers expect to be able to use
1439         this section to obtain intelligible stack traces, otherwise we
1440         just number the wasm functions which is somewhat painful.
1441
1442         This patch parses this section, dropping its content eagerly on
1443         error, and if there is a name section then backtraces use their
1444         value instead of numbers. Otherwise we stick to numbers as before.
1445
1446         Note that the format of name sections changed in mid-February:
1447           https://github.com/WebAssembly/design/pull/984
1448         And binaryen was only updated in early March:
1449           https://github.com/WebAssembly/binaryen/pull/933
1450
1451         * CMakeLists.txt:
1452         * JavaScriptCore.xcodeproj/project.pbxproj:
1453         * interpreter/Interpreter.cpp:
1454         (JSC::GetStackTraceFunctor::operator()):
1455         * interpreter/StackVisitor.cpp:
1456         (JSC::StackVisitor::readNonInlinedFrame):
1457         (JSC::StackVisitor::Frame::functionName):
1458         * interpreter/StackVisitor.h:
1459         (JSC::StackVisitor::Frame::wasmFunctionIndexOrName):
1460         * runtime/StackFrame.cpp:
1461         (JSC::StackFrame::functionName):
1462         * runtime/StackFrame.h:
1463         (JSC::StackFrame::StackFrame):
1464         (JSC::StackFrame::wasm):
1465         * wasm/WasmBBQPlanInlines.h:
1466         (JSC::Wasm::BBQPlan::initializeCallees):
1467         * wasm/WasmCallee.cpp:
1468         (JSC::Wasm::Callee::Callee):
1469         * wasm/WasmCallee.h:
1470         (JSC::Wasm::Callee::create):
1471         (JSC::Wasm::Callee::indexOrName):
1472         * wasm/WasmFormat.cpp:
1473         (JSC::Wasm::makeString):
1474         * wasm/WasmFormat.h:
1475         (JSC::Wasm::isValidExternalKind):
1476         (JSC::Wasm::isValidNameType):
1477         (JSC::Wasm::NameSection::get):
1478         * wasm/WasmIndexOrName.cpp: Copied from Source/JavaScriptCore/wasm/WasmCallee.cpp.
1479         (JSC::Wasm::IndexOrName::IndexOrName):
1480         (JSC::Wasm::makeString):
1481         * wasm/WasmIndexOrName.h: Copied from Source/JavaScriptCore/wasm/WasmFormat.cpp.
1482         * wasm/WasmModuleInformation.h:
1483         * wasm/WasmModuleParser.cpp:
1484         * wasm/WasmName.h: Copied from Source/JavaScriptCore/wasm/WasmCallee.cpp.
1485         * wasm/WasmNameSectionParser.cpp: Added.
1486         * wasm/WasmNameSectionParser.h: Copied from Source/JavaScriptCore/wasm/WasmCallee.cpp.
1487         (JSC::Wasm::NameSectionParser::NameSectionParser):
1488         * wasm/WasmOMGPlan.cpp:
1489         (JSC::Wasm::OMGPlan::work):
1490         * wasm/WasmParser.h:
1491         (JSC::Wasm::Parser<SuccessType>::consumeUTF8String):
1492
1493 2017-05-10  Filip Pizlo  <fpizlo@apple.com>
1494
1495         Null pointer dereference in WTF::RefPtr<WTF::StringImpl>::operator!() under slow_path_get_direct_pname
1496         https://bugs.webkit.org/show_bug.cgi?id=171801
1497
1498         Reviewed by Michael Saboff.
1499         
1500         This was a goofy oversight. The for-in optimization relies on the bytecode generator
1501         to detect when the loop's index variable gets mutated. We forgot to have the hooks for
1502         detecting this in prefix and postfix operations (++i and i++).
1503
1504         * bytecompiler/NodesCodegen.cpp:
1505         (JSC::PostfixNode::emitResolve):
1506         (JSC::PrefixNode::emitResolve):
1507
1508 2017-05-10  Michael Catanzaro  <mcatanzaro@igalia.com>
1509
1510         [GTK] -Wmissing-field-initializers triggered by RemoteInspectorServer.cpp:128
1511         https://bugs.webkit.org/show_bug.cgi?id=171273
1512
1513         Reviewed by Carlos Garcia Campos.
1514
1515         * inspector/remote/glib/RemoteInspectorGlib.cpp:
1516         * inspector/remote/glib/RemoteInspectorServer.cpp:
1517
1518 2017-05-10  Adrian Perez de Castro  <aperez@igalia.com>
1519
1520         Remove some last remnants of the EFL port
1521         https://bugs.webkit.org/show_bug.cgi?id=171922
1522
1523         Reviewed by Antonio Gomes.
1524
1525         The EFL port is no more.
1526
1527         * PlatformEfl.cmake: Removed.
1528         * shell/PlatformEfl.cmake: Removed.
1529
1530 2017-05-09  Filip Pizlo  <fpizlo@apple.com>
1531
1532         JSInjectedScriptHost should get a copy of the boundArgs
1533         https://bugs.webkit.org/show_bug.cgi?id=171897
1534
1535         Reviewed by Joseph Pecoraro.
1536         
1537         The boundArgs array is very special - it cannot be mutated in any way. So, it makes sense
1538         for the inspector to get a copy of it.
1539
1540         * inspector/JSInjectedScriptHost.cpp:
1541         (Inspector::JSInjectedScriptHost::getInternalProperties):
1542         * runtime/JSBoundFunction.cpp:
1543         (JSC::JSBoundFunction::boundArgsCopy):
1544         * runtime/JSBoundFunction.h:
1545         (JSC::JSBoundFunction::boundArgs):
1546
1547 2017-05-09  Mark Lam  <mark.lam@apple.com>
1548
1549         Unindent some code in Watchdog::shouldTerminate().
1550         https://bugs.webkit.org/show_bug.cgi?id=171896
1551
1552         Rubber stamped by Keith Miller.
1553
1554         I should have done this before I landed r213107, but I forgot.  Unindenting it now.
1555
1556         * runtime/Watchdog.cpp:
1557         (JSC::Watchdog::shouldTerminate):
1558
1559 2017-05-09  Michael Saboff  <msaboff@apple.com>
1560
1561         Cap the number of FTL compilation threads on iOS to 2
1562         https://bugs.webkit.org/show_bug.cgi?id=171887
1563
1564         Reviewed by Filip Pizlo.
1565
1566         Set an iOS specific max of 2 threads.
1567
1568         * runtime/Options.h:
1569
1570 2017-05-09  Filip Pizlo  <fpizlo@apple.com>
1571
1572         Heap::heap() should behave gracefully for null pointers
1573         https://bugs.webkit.org/show_bug.cgi?id=171888
1574         <rdar://problem/32005315>
1575
1576         Reviewed by Mark Lam.
1577         
1578         Some callers of Heap::heap() can pass a null cell and they will behave gracefully if we
1579         return a null Heap. So, let's do that.
1580         
1581         This fixes a crash and it does not hurt performance. I'm seeing a possible 0.5% regression
1582         with 74% probability. That's a neutral result by our usual 95% standard.
1583
1584         * heap/HeapInlines.h:
1585         (JSC::Heap::heap):
1586
1587 2017-05-09  Yusuke Suzuki  <utatane.tea@gmail.com>
1588
1589         Handle IDLPromise<> properly
1590         https://bugs.webkit.org/show_bug.cgi?id=166752
1591
1592         Reviewed by Youenn Fablet.
1593
1594         Add JSPromise::resolve static function.
1595         This applies `Promise.resolve()` conversion to a given value.
1596
1597         * runtime/JSGlobalObject.cpp:
1598         (JSC::JSGlobalObject::init):
1599         (JSC::JSGlobalObject::visitChildren):
1600         * runtime/JSGlobalObject.h:
1601         (JSC::JSGlobalObject::promiseResolveFunction):
1602         * runtime/JSPromise.cpp:
1603         (JSC::JSPromise::resolve):
1604         * runtime/JSPromise.h:
1605
1606 2017-05-09  Zan Dobersek  <zdobersek@igalia.com>
1607
1608         Upstream the WPE port
1609         https://bugs.webkit.org/show_bug.cgi?id=171110
1610
1611         Reviewed by Alex Christensen.
1612
1613         * PlatformWPE.cmake: Added.
1614         * shell/PlatformWPE.cmake: Added.
1615
1616 2017-05-09  Saam Barati  <sbarati@apple.com>
1617
1618         CallLinkInfos belonging to Wasm->JS stubs need to be informed when we clearCode() from all Executables
1619         https://bugs.webkit.org/show_bug.cgi?id=171707
1620         <rdar://problem/31891649>
1621
1622         Reviewed by Filip Pizlo.
1623
1624         This patch fixes a bug where a Wasm->JS IC call stub would go stale
1625         and point into a CodeBlock no longer owned by any executable. The
1626         problematic scenario is this:
1627
1628         1. We generate the call IC which has a branch on a callee check. This
1629            callee owns the Executable in question. If the branch succeeds, it
1630            will call code belonging to a particular CodeBlock associated with
1631            that Executable.
1632
1633         2. Heap::deleteAllCodeBlocks is called. This leads the Executable to clear
1634            its various CodeBlock references.
1635
1636         3. Wasm has no idea this happened, so now it has stale ICs that point into
1637            code from a CodeBlock no longer belonging to an Executable.
1638
1639         This patch fixes the bug by informing all JSWebAssemblyCodeBlocks to unlink
1640         their CallLinkInfo when Heap::deleteAllCodeBlocks is called.
1641
1642         We track all JSWebAssemblyCodeBlocks by creating a new subspace for them.
1643         This allows us to quickly iterate over the live JSWebAssemblyCodeBlocks in the
1644         heap.
1645
1646         * CMakeLists.txt:
1647         * JavaScriptCore.xcodeproj/project.pbxproj:
1648         * heap/Heap.cpp:
1649         (JSC::Heap::deleteAllCodeBlocks):
1650         * heap/Subspace.h:
1651         * heap/SubspaceInlines.h:
1652         (JSC::Subspace::forEachLiveCell):
1653         * runtime/VM.cpp:
1654         (JSC::VM::VM):
1655         * runtime/VM.h:
1656         * wasm/js/JSWebAssemblyCodeBlock.cpp:
1657         (JSC::JSWebAssemblyCodeBlock::clearJSCallICs):
1658         * wasm/js/JSWebAssemblyCodeBlock.h:
1659         (JSC::JSWebAssemblyCodeBlock::createStructure): Deleted.
1660         (JSC::JSWebAssemblyCodeBlock::functionImportCount): Deleted.
1661         (JSC::JSWebAssemblyCodeBlock::module): Deleted.
1662         (JSC::JSWebAssemblyCodeBlock::jsEntrypointCalleeFromFunctionIndexSpace): Deleted.
1663         (JSC::JSWebAssemblyCodeBlock::wasmEntrypointLoadLocationFromFunctionIndexSpace): Deleted.
1664         (JSC::JSWebAssemblyCodeBlock::wasmToJsCallStubForImport): Deleted.
1665         (JSC::JSWebAssemblyCodeBlock::offsetOfImportWasmToJSStub): Deleted.
1666         (JSC::JSWebAssemblyCodeBlock::codeBlock): Deleted.
1667         (JSC::JSWebAssemblyCodeBlock::offsetOfImportStubs): Deleted.
1668         (JSC::JSWebAssemblyCodeBlock::allocationSize): Deleted.
1669         (JSC::JSWebAssemblyCodeBlock::importWasmToJSStub): Deleted.
1670         * wasm/js/JSWebAssemblyCodeBlockSubspace.cpp: Added.
1671         (JSC::JSWebAssemblyCodeBlockSubspace::JSWebAssemblyCodeBlockSubspace):
1672         (JSC::JSWebAssemblyCodeBlockSubspace::~JSWebAssemblyCodeBlockSubspace):
1673         (JSC::JSWebAssemblyCodeBlockSubspace::finishSweep):
1674         (JSC::JSWebAssemblyCodeBlockSubspace::destroy):
1675         * wasm/js/JSWebAssemblyCodeBlockSubspace.h: Added.
1676
1677 2017-05-08  Saam Barati  <sbarati@apple.com>
1678
1679         testWasmBoundsCheck and testCallFunctionWithHellaArguments is broken in testb3
1680         https://bugs.webkit.org/show_bug.cgi?id=171392
1681         <rdar://problem/31872222>
1682
1683         Reviewed by Keith Miller.
1684
1685         This patch fixes two bugs. The first one is:
1686         Inside testb3, we were using the wrong WasmBoundsCheckValue constructor.
1687         Everything compiled OK because of implicit casting in C. I've changed one
1688         of the constructors to take arguments in a different order so we don't
1689         run into this problem again.
1690         
1691         The second bug was that Air::ShufflePair::inst was assuming that a move
1692         from BigImm to its destination is always valid. This is not the case.
1693         For example, the store, `Move BigImm, Addr` is not allowed. I refactored
1694         the code to be correct by emitting more than one instruction when needeed.
1695         
1696         When testing my changes, I ran ARM64 testb3 both in debug and
1697         release. I ran into many pre-existing failures. I've opened
1698         a new bug to fix those here: https://bugs.webkit.org/show_bug.cgi?id=171826
1699
1700         * b3/B3WasmBoundsCheckValue.cpp:
1701         (JSC::B3::WasmBoundsCheckValue::WasmBoundsCheckValue):
1702         * b3/B3WasmBoundsCheckValue.h:
1703         * b3/air/AirEmitShuffle.cpp:
1704         (JSC::B3::Air::ShufflePair::insts):
1705         (JSC::B3::Air::ShufflePair::inst): Deleted.
1706         * b3/air/AirEmitShuffle.h:
1707         * b3/air/AirLowerMacros.cpp:
1708         (JSC::B3::Air::lowerMacros):
1709         * b3/testb3.cpp:
1710         (JSC::B3::testLoadAcq42):
1711         (JSC::B3::testStoreRelAddLoadAcq32):
1712         (JSC::B3::testStoreRelAddLoadAcq8):
1713         (JSC::B3::testStoreRelAddFenceLoadAcq8):
1714         (JSC::B3::testStoreRelAddLoadAcq16):
1715         (JSC::B3::testStoreRelAddLoadAcq64):
1716         (JSC::B3::testSimplePatchpointWithOuputClobbersGPArgs):
1717         (JSC::B3::testCheckMul):
1718         (JSC::B3::testCheckMulMemory):
1719         (JSC::B3::testCheckMul64):
1720         (JSC::B3::testCheckMulFold):
1721         (JSC::B3::testCheckMulFoldFail):
1722         (JSC::B3::testCheckMulArgumentAliasing64):
1723         (JSC::B3::testCheckMulArgumentAliasing32):
1724         (JSC::B3::testCheckMul64SShr):
1725         (JSC::B3::testCallFunctionWithHellaArguments):
1726         (JSC::B3::functionWithHellaArguments2):
1727         (JSC::B3::testCallFunctionWithHellaArguments2):
1728         (JSC::B3::functionWithHellaArguments3):
1729         (JSC::B3::testCallFunctionWithHellaArguments3):
1730         (JSC::B3::testSpillDefSmallerThanUse):
1731         (JSC::B3::testLateRegister):
1732         (JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled):
1733         (JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled2):
1734         (JSC::B3::testMoveConstants):
1735         (JSC::B3::testAtomicWeakCAS):
1736         (JSC::B3::testAtomicStrongCAS):
1737         (JSC::B3::testAtomicXchg):
1738         (JSC::B3::testWasmBoundsCheck):
1739         (JSC::B3::run):
1740         * wasm/WasmB3IRGenerator.cpp:
1741         (JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer):
1742
1743 2017-05-08  Filip Pizlo  <fpizlo@apple.com>
1744
1745         Expose a function to get proxy targets
1746         https://bugs.webkit.org/show_bug.cgi?id=171797
1747         <rdar://problem/32027549>
1748
1749         Reviewed by Mark Lam.
1750         
1751         This exposes a new private API function, JSObjectGetProxyTarget(), that gets the target of a
1752         proxy. It works with both ProxyObject and JSProxy, but it's primarily intended for use with
1753         JSProxy.
1754
1755         * API/JSObjectRef.cpp:
1756         (JSObjectGetProxyTarget):
1757         * API/JSObjectRefPrivate.h:
1758         * API/tests/JSObjectGetProxyTargetTest.cpp: Added.
1759         (testJSObjectGetProxyTarget):
1760         * API/tests/JSObjectGetProxyTargetTest.h: Added.
1761         * API/tests/testapi.c:
1762         (main):
1763         * JavaScriptCore.xcodeproj/project.pbxproj:
1764         * runtime/ProxyObject.h:
1765         * shell/PlatformWin.cmake: 
1766
1767 2017-05-08  Mark Lam  <mark.lam@apple.com>
1768
1769         op_throw_static_error's use of its first operand should be reflected in DFG BytecodeUseDef as well.
1770         https://bugs.webkit.org/show_bug.cgi?id=171786
1771         <rdar://problem/32051023>
1772
1773         Reviewed by Saam Barati.
1774
1775         * bytecode/BytecodeDumper.cpp:
1776         (JSC::BytecodeDumper<Block>::dumpBytecode):
1777         - Fix BytecodeDumper to dump op_throw_static_error correctly.  Previously,
1778           it was expecting op1 to always be a constant.  r206870 changed it to take a
1779           variable string as well.
1780
1781         * bytecode/BytecodeUseDef.h:
1782         (JSC::computeUsesForBytecodeOffset):
1783         - Fix the bug.
1784
1785         * dfg/DFGByteCodeParser.cpp:
1786         (JSC::DFG::ByteCodeParser::parseBlock):
1787         - Move the Phantom of op1 after the ThrowStaticError node, because technically,
1788           the ThrowStaticError represents op_throw_static_error, and op_throw_static_error
1789           uses op1.  In practice, this probably doesn't matter, but let's have the code
1790           accurately communicate the behavior we're expecting.
1791
1792 2017-05-08  JF Bastien  <jfbastien@apple.com>
1793
1794         WebAssembly: don't just emit extended offset adds for patch
1795         https://bugs.webkit.org/show_bug.cgi?id=171799
1796
1797         Reviewed by Mark Lam.
1798
1799         It isn't necessary to restrict.
1800
1801         * b3/air/AirLowerStackArgs.cpp:
1802         (JSC::B3::Air::lowerStackArgs):
1803
1804 2017-05-08  Mark Lam  <mark.lam@apple.com>
1805
1806         Introduce ExceptionScope::assertNoException() and releaseAssertNoException().
1807         https://bugs.webkit.org/show_bug.cgi?id=171776
1808
1809         Reviewed by Keith Miller.
1810
1811         Instead of ASSERT(!scope.exception()), we can now do scope.assertNoException().
1812         Ditto for RELEASE_ASSERT and scope.releaseAssertNoException().  
1813
1814         The advantage of using ExceptionScope::assertNoException() and
1815         releaseAssertNoException() is that if the assertion fails, these utility
1816         functions will print the stack trace for where the unexpected exception is
1817         detected as well as where the unexpected exception was thrown from.  This makes
1818         it much easier to debug the source of unhandled exceptions.
1819
1820         * debugger/Debugger.cpp:
1821         (JSC::Debugger::pauseIfNeeded):
1822         * dfg/DFGOperations.cpp:
1823         * interpreter/Interpreter.cpp:
1824         (JSC::eval):
1825         (JSC::notifyDebuggerOfUnwinding):
1826         (JSC::Interpreter::executeProgram):
1827         (JSC::Interpreter::executeCall):
1828         (JSC::Interpreter::executeConstruct):
1829         (JSC::Interpreter::prepareForRepeatCall):
1830         (JSC::Interpreter::execute):
1831         (JSC::Interpreter::debug):
1832         * interpreter/ShadowChicken.cpp:
1833         (JSC::ShadowChicken::functionsOnStack):
1834         * jsc.cpp:
1835         (GlobalObject::moduleLoaderResolve):
1836         (GlobalObject::moduleLoaderFetch):
1837         (functionGenerateHeapSnapshot):
1838         (functionSamplingProfilerStackTraces):
1839         (box):
1840         (runWithScripts):
1841         * runtime/AbstractModuleRecord.cpp:
1842         (JSC::AbstractModuleRecord::finishCreation):
1843         * runtime/ArrayPrototype.cpp:
1844         (JSC::ArrayPrototype::tryInitializeSpeciesWatchpoint):
1845         * runtime/Completion.cpp:
1846         (JSC::rejectPromise):
1847         * runtime/ErrorInstance.cpp:
1848         (JSC::ErrorInstance::sanitizedToString):
1849         * runtime/ExceptionHelpers.cpp:
1850         (JSC::createError):
1851         * runtime/ExceptionScope.cpp:
1852         (JSC::ExceptionScope::unexpectedExceptionMessage):
1853         * runtime/ExceptionScope.h:
1854         (JSC::ExceptionScope::assertNoException):
1855         (JSC::ExceptionScope::releaseAssertNoException):
1856         (JSC::ExceptionScope::unexpectedExceptionMessage):
1857         * runtime/GenericArgumentsInlines.h:
1858         (JSC::GenericArguments<Type>::defineOwnProperty):
1859         * runtime/IntlCollator.cpp:
1860         (JSC::IntlCollator::createCollator):
1861         (JSC::IntlCollator::resolvedOptions):
1862         * runtime/IntlDateTimeFormat.cpp:
1863         (JSC::IntlDateTimeFormat::resolvedOptions):
1864         (JSC::IntlDateTimeFormat::format):
1865         * runtime/IntlNumberFormat.cpp:
1866         (JSC::IntlNumberFormat::createNumberFormat):
1867         (JSC::IntlNumberFormat::resolvedOptions):
1868         * runtime/JSCJSValue.cpp:
1869         (JSC::JSValue::putToPrimitiveByIndex):
1870         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
1871         (JSC::genericTypedArrayViewProtoFuncIncludes):
1872         (JSC::genericTypedArrayViewProtoFuncIndexOf):
1873         (JSC::genericTypedArrayViewProtoFuncLastIndexOf):
1874         (JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
1875         * runtime/JSGlobalObject.cpp:
1876         (JSC::JSGlobalObject::init):
1877         * runtime/JSGlobalObjectFunctions.cpp:
1878         (JSC::globalFuncHostPromiseRejectionTracker):
1879         * runtime/JSModuleEnvironment.cpp:
1880         (JSC::JSModuleEnvironment::getOwnPropertySlot):
1881         * runtime/JSModuleLoader.cpp:
1882         (JSC::JSModuleLoader::finishCreation):
1883         * runtime/JSModuleNamespaceObject.cpp:
1884         (JSC::JSModuleNamespaceObject::finishCreation):
1885         * runtime/JSONObject.cpp:
1886         (JSC::Stringifier::toJSON):
1887         * runtime/JSObject.cpp:
1888         (JSC::JSObject::ordinaryToPrimitive):
1889         * runtime/JSPropertyNameEnumerator.h:
1890         (JSC::propertyNameEnumerator):
1891         * runtime/ObjectConstructor.cpp:
1892         (JSC::objectConstructorGetOwnPropertyDescriptors):
1893         (JSC::objectConstructorDefineProperty):
1894         * runtime/ObjectPrototype.cpp:
1895         (JSC::objectProtoFuncHasOwnProperty):
1896         * runtime/ProgramExecutable.cpp:
1897         (JSC::ProgramExecutable::initializeGlobalProperties):
1898         * runtime/ReflectObject.cpp:
1899         (JSC::reflectObjectDefineProperty):
1900         * runtime/SamplingProfiler.cpp:
1901         (JSC::SamplingProfiler::StackFrame::nameFromCallee):
1902         * runtime/StringPrototype.cpp:
1903         (JSC::stringProtoFuncRepeatCharacter):
1904         * runtime/TemplateRegistry.cpp:
1905         (JSC::TemplateRegistry::getTemplateObject):
1906         * runtime/VM.cpp:
1907         (JSC::VM::throwException):
1908         * runtime/VM.h:
1909         (JSC::VM::nativeStackTraceOfLastThrow):
1910         (JSC::VM::clearException):
1911         * wasm/WasmB3IRGenerator.cpp:
1912         * wasm/js/JSWebAssemblyInstance.cpp:
1913         (JSC::JSWebAssemblyInstance::create):
1914
1915 2017-05-06  Bill Ming  <mbbill@gmail.com>
1916
1917         Fix 32bit Windows build by giving correct parameters to MASM
1918         https://bugs.webkit.org/show_bug.cgi?id=170833
1919
1920         Reviewed by Alex Christensen.
1921
1922         * CMakeLists.txt:
1923
1924 2017-05-06  Oleksandr Skachkov  <gskachkov@gmail.com>
1925
1926         [ES6] Arrow function. Issue in access to this after eval('super()') within constructor
1927         https://bugs.webkit.org/show_bug.cgi?id=171543
1928
1929         Reviewed by Saam Barati.
1930
1931         Current patch force to use 'this' within arrow function or eval 
1932         from virtual scope each time, instead of using thisRegister.
1933
1934         * bytecompiler/BytecodeGenerator.cpp:
1935         (JSC::BytecodeGenerator::ensureThis):
1936
1937 2017-05-05  Keith Miller  <keith_miller@apple.com>
1938
1939         Put does not properly consult the prototype chain
1940         https://bugs.webkit.org/show_bug.cgi?id=171754
1941
1942         Reviewed by Saam Barati.
1943
1944         We should do a follow up that cleans up the rest of put. See:
1945         https://bugs.webkit.org/show_bug.cgi?id=171759
1946
1947         * runtime/JSCJSValue.cpp:
1948         (JSC::JSValue::putToPrimitive):
1949         * runtime/JSObject.cpp:
1950         (JSC::JSObject::putInlineSlow):
1951         * runtime/JSObjectInlines.h:
1952         (JSC::JSObject::canPerformFastPutInline):
1953
1954 2017-05-05  JF Bastien  <jfbastien@apple.com>
1955
1956         WebAssembly: Air::Inst::generate crashes on large binary on A64
1957         https://bugs.webkit.org/show_bug.cgi?id=170215
1958
1959         Reviewed by Filip Pizlo.
1960
1961         ARM can't encode all offsets in a single instruction. We usualy
1962         handle this type of detail early, or the macro assembler uses a
1963         scratch register to take care of the large immediate. After
1964         register allocation we assumed that we would never get large
1965         offsets, and asserted this was the case. That was a fine
1966         assumption with JavaScript, but WebAssembly ends up generating
1967         stack frames which are too big to encode.
1968
1969         There are two places that needed to be fixed:
1970             1. AirGenerate
1971             2. AirLowerStackArgs
1972
1973         We now unconditionally pin the dataTempRegister on ARM64, and use
1974         it when immediates don't fit.
1975
1976         Number 1. is easy: we're just incrementing SP, make sure we can
1977         use a scratch register when that happens.
1978
1979         Number 2. is more complex: not all Inst can receive a stack
1980         argument whose base register isn't SP or FP. Specifically,
1981         Patchpoints and Stackmaps get very sad because they just want to
1982         know the offset value, but when we materialize the offset as
1983         follows:
1984
1985             Move (spill337), (spill201), %r0, @8735
1986
1987         Becomes (where %r16 is dataTempRegister):
1988             Move $1404, %r16, @8736
1989             Add64 %sp, %r16, @8736
1990             Move (%r16), 2032(%sp), %r0, @8736
1991
1992         The code currently doesn't see through our little dance. To work
1993         around this issue we introduce a new Air Arg kind:
1994         ExtendedOffsetAddr. This is the same as a regular Addr, but with
1995         an offset which may be too big to encode. Opcodes then declare
1996         whether their arguments can handle such inputs, and if so we
1997         generate them, otherwise we generate Addr as shown above.
1998
1999         None of this affects x86 because it can always encode large
2000         immediates.
2001
2002         This patch also drive-by converts some uses of `override` to
2003         `final`. It makes the code easier to grok, and maybe helps the
2004         optimizer sometimes but really that doens't matter.
2005
2006         * assembler/MacroAssembler.h:
2007         * assembler/MacroAssemblerARM64.h:
2008         * b3/B3CheckSpecial.cpp:
2009         (JSC::B3::CheckSpecial::admitsExtendedOffsetAddr):
2010         * b3/B3CheckSpecial.h:
2011         * b3/B3Common.cpp:
2012         (JSC::B3::pinnedExtendedOffsetAddrRegister): keep the CPU-specific
2013         pinning information in a cpp file
2014         * b3/B3Common.h:
2015         * b3/B3PatchpointSpecial.cpp:
2016         (JSC::B3::PatchpointSpecial::admitsExtendedOffsetAddr):
2017         * b3/B3PatchpointSpecial.h:
2018         * b3/B3StackmapSpecial.cpp:
2019         (JSC::B3::StackmapSpecial::isArgValidForRep):
2020         (JSC::B3::StackmapSpecial::repForArg):
2021         * b3/B3StackmapSpecial.h:
2022         * b3/air/AirArg.cpp:
2023         (JSC::B3::Air::Arg::isStackMemory):
2024         (JSC::B3::Air::Arg::jsHash):
2025         (JSC::B3::Air::Arg::dump):
2026         (WTF::printInternal):
2027         (JSC::B3::Air::Arg::stackAddrImpl): Deleted. There was only one
2028         use of this (in AirLowerStackArgs) and it was now confusing to
2029         split the logic up between these two. Inline the code that used to
2030         be here into its one usepoint instead.
2031         * b3/air/AirArg.h:
2032         (JSC::B3::Air::Arg::extendedOffsetAddr):
2033         (JSC::B3::Air::Arg::isExtendedOffsetAddr):
2034         (JSC::B3::Air::Arg::isMemory):
2035         (JSC::B3::Air::Arg::base):
2036         (JSC::B3::Air::Arg::offset):
2037         (JSC::B3::Air::Arg::isGP):
2038         (JSC::B3::Air::Arg::isFP):
2039         (JSC::B3::Air::Arg::isValidForm):
2040         (JSC::B3::Air::Arg::forEachTmpFast):
2041         (JSC::B3::Air::Arg::forEachTmp):
2042         (JSC::B3::Air::Arg::asAddress):
2043         (JSC::B3::Air::Arg::stackAddr): Deleted.
2044         * b3/air/AirCCallSpecial.cpp:
2045         (JSC::B3::Air::CCallSpecial::isValid):
2046         (JSC::B3::Air::CCallSpecial::admitsExtendedOffsetAddr):
2047         (JSC::B3::Air::CCallSpecial::generate):
2048         * b3/air/AirCCallSpecial.h:
2049         * b3/air/AirCode.cpp:
2050         (JSC::B3::Air::Code::Code):
2051         (JSC::B3::Air::Code::pinRegister): Check that the register wasn't
2052         pinned before pinning it. It's likely a bug to pin the same
2053         register twice.
2054         * b3/air/AirCustom.h:
2055         (JSC::B3::Air::PatchCustom::admitsExtendedOffsetAddr):
2056         (JSC::B3::Air::CCallCustom::admitsExtendedOffsetAddr):
2057         (JSC::B3::Air::ShuffleCustom::admitsExtendedOffsetAddr):
2058         (JSC::B3::Air::EntrySwitchCustom::admitsExtendedOffsetAddr):
2059         (JSC::B3::Air::WasmBoundsCheckCustom::admitsExtendedOffsetAddr):
2060         * b3/air/AirGenerate.cpp:
2061         (JSC::B3::Air::generate):
2062         * b3/air/AirInst.h:
2063         * b3/air/AirInstInlines.h:
2064         (JSC::B3::Air::Inst::admitsExtendedOffsetAddr):
2065         * b3/air/AirLowerStackArgs.cpp:
2066         (JSC::B3::Air::lowerStackArgs):
2067         * b3/air/AirPrintSpecial.cpp:
2068         (JSC::B3::Air::PrintSpecial::admitsExtendedOffsetAddr):
2069         (JSC::B3::Air::PrintSpecial::generate):
2070         * b3/air/AirPrintSpecial.h:
2071         * b3/air/AirSpecial.h:
2072         * b3/air/opcode_generator.rb:
2073
2074 2017-05-05  Oliver Hunt  <oliver@apple.com>
2075
2076         Move trivial String prototype functions to JS builtins
2077         https://bugs.webkit.org/show_bug.cgi?id=171737
2078
2079         Reviewed by Saam Barati.
2080
2081         Super simple change to migrate all of the old school
2082         html-ifying string operations to builtin JS.
2083
2084         Core implementation is basically a 1-for-1 match to the spec.
2085
2086         * builtins/StringPrototype.js:
2087         (globalPrivate.createHTML):
2088         (anchor):
2089         (big):
2090         (blink):
2091         (bold):
2092         (fixed):
2093         (fontcolor):
2094         (fontsize):
2095         (italics):
2096         (link):
2097         (small):
2098         (strike):
2099         (sub):
2100         (sup):
2101         * runtime/StringPrototype.cpp:
2102         (JSC::StringPrototype::finishCreation):
2103         (JSC::stringProtoFuncBig): Deleted.
2104         (JSC::stringProtoFuncSmall): Deleted.
2105         (JSC::stringProtoFuncBlink): Deleted.
2106         (JSC::stringProtoFuncBold): Deleted.
2107         (JSC::stringProtoFuncFixed): Deleted.
2108         (JSC::stringProtoFuncItalics): Deleted.
2109         (JSC::stringProtoFuncStrike): Deleted.
2110         (JSC::stringProtoFuncSub): Deleted.
2111         (JSC::stringProtoFuncSup): Deleted.
2112         (JSC::stringProtoFuncFontcolor): Deleted.
2113         (JSC::stringProtoFuncFontsize): Deleted.
2114         (JSC::stringProtoFuncAnchor): Deleted.
2115         (JSC::stringProtoFuncLink): Deleted.
2116
2117 2017-05-05  Don Olmstead  <don.olmstead@am.sony.com>
2118
2119         [JSC] Remove export from Intrinsic
2120         https://bugs.webkit.org/show_bug.cgi?id=171752
2121
2122         Reviewed by Alexey Proskuryakov.
2123
2124         * runtime/Intrinsic.h:
2125
2126 2017-05-05  Saam Barati  <sbarati@apple.com>
2127
2128         putDirectIndex does not properly do defineOwnProperty
2129         https://bugs.webkit.org/show_bug.cgi?id=171591
2130         <rdar://problem/31735695>
2131
2132         Reviewed by Geoffrey Garen.
2133
2134         This patch fixes putDirectIndex and its JIT implementations to be
2135         compatible with the ES6 spec. I think our code became out of date
2136         when we implemented ArraySpeciesCreate since ArraySpeciesCreate may
2137         return arbitrary objects. We perform putDirectIndex on that arbitrary
2138         object. The behavior we want is as if we performed defineProperty({configurable:true, enumerable:true, writable:true}).
2139         However, we weren't doing this. putDirectIndex assumed it could just splat
2140         data into any descendent of JSObject's butterfly. For example, this means
2141         we'd just splat into the butterfly of a typed array, even though a typed
2142         array doesn't use its butterfly to store its indexed properties in the usual
2143         way. Also, typed array properties are non-configurable, so this operation
2144         should throw. This also means if we saw a ProxyObject, we'd just splat
2145         into its butterfly, but this is obviously wrong because ProxyObject should
2146         intercept the defineProperty operation.
2147         
2148         This patch fixes this issue by adding a whitelist of cell types that can
2149         go down putDirectIndex's fast path. Anything not in that whitelist will
2150         simply call into defineOwnProperty.
2151
2152         * bytecode/ByValInfo.h:
2153         (JSC::jitArrayModePermitsPutDirect):
2154         * dfg/DFGArrayMode.cpp:
2155         (JSC::DFG::ArrayMode::refine):
2156         * jit/JITOperations.cpp:
2157         * runtime/ArrayPrototype.cpp:
2158         (JSC::arrayProtoFuncSplice):
2159         * runtime/ClonedArguments.cpp:
2160         (JSC::ClonedArguments::createStructure):
2161         * runtime/JSGenericTypedArrayViewInlines.h:
2162         (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
2163         * runtime/JSObject.cpp:
2164         (JSC::canDoFastPutDirectIndex):
2165         (JSC::JSObject::defineOwnIndexedProperty):
2166         (JSC::JSObject::putDirectIndexSlowOrBeyondVectorLength):
2167         (JSC::JSObject::putDirectIndexBeyondVectorLength): Deleted.
2168         * runtime/JSObject.h:
2169         (JSC::JSObject::putDirectIndex):
2170         (JSC::JSObject::canSetIndexQuicklyForPutDirect): Deleted.
2171         * runtime/JSType.h:
2172
2173 2017-05-05  Guillaume Emont  <guijemont@igalia.com>
2174
2175         [JSC] include JSCInlines.h in ObjectInitializationScope.cpp
2176         https://bugs.webkit.org/show_bug.cgi?id=171744
2177
2178         Reviewed by Mark Lam.
2179
2180         * runtime/ObjectInitializationScope.cpp:
2181
2182
2183 2017-05-05  Carlos Garcia Campos  <cgarcia@igalia.com>
2184
2185         [GTK] Assertion failure in Inspector::RemoteInspector::setRemoteInspectorClient when disposing WebKitWebContext
2186         https://bugs.webkit.org/show_bug.cgi?id=171644
2187
2188         Reviewed by Michael Catanzaro.
2189
2190         Fix ASSERT that requires given client to be a valid pointer, since it's valid to pass nullptr to unset the
2191         client. The ASSERT now ensures that client is set or unset. I also renamed the function to setClient because
2192         setRemoteInspectorClient is redundant for a class named RemoteInspector. And added a getter too, to check if the
2193         remote inspector has a client.
2194
2195         * inspector/remote/RemoteInspector.cpp:
2196         (Inspector::RemoteInspector::setClient):
2197         * inspector/remote/RemoteInspector.h:
2198
2199 2017-05-04  Commit Queue  <commit-queue@webkit.org>
2200
2201         Unreviewed, rolling out r216206.
2202         https://bugs.webkit.org/show_bug.cgi?id=171714
2203
2204         Multiple LayoutTests crashing in Document::page() (Requested
2205         by ap on #webkit).
2206
2207         Reverted changeset:
2208
2209         "Remove support for legacy Notifications"
2210         https://bugs.webkit.org/show_bug.cgi?id=171487
2211         http://trac.webkit.org/changeset/216206
2212
2213 2017-05-04  Don Olmstead  <don.olmstead@am.sony.com>
2214
2215         [Win] Remove redundant macros that are set in the CMake config
2216         https://bugs.webkit.org/show_bug.cgi?id=171571
2217
2218         Reviewed by Brent Fulgham.
2219
2220         * config.h:
2221
2222 2017-05-04  Mark Lam  <mark.lam@apple.com>
2223
2224         Gardening: Build fix for Windows after r216217.
2225         https://bugs.webkit.org/show_bug.cgi?id=171586
2226
2227         Not reviewed.
2228
2229         * shell/PlatformWin.cmake:
2230
2231 2017-05-04  Filip Pizlo  <fpizlo@apple.com>
2232
2233         JSC::Heap should expose a richer API for requesting GCs
2234         https://bugs.webkit.org/show_bug.cgi?id=171690
2235
2236         Reviewed by Geoffrey Garen.
2237         
2238         I want to stop WebCore from requesting synchronous GCs. But various parts of that work
2239         may cause regressions, so I'd like to land it separately from the functionality that is
2240         needed on the JSC side. This change is mostly a JSC-side refactoring that does not
2241         change behavior. In the future I'll land the behavior changes (i.e. not requesting sync
2242         GCs).
2243         
2244         This change allows you to enumerate over synchronousness, so that we can make all APIs
2245         take synchronousness as an argument. It replaces the collectAllGarbage API with a
2246         collectNow(Synchronousness, GCRequest) API. GCRequest is a new concept, which subsumes
2247         std::optional<CollectionScope> and gives us the ability to register callbacks along
2248         with a GC. So, you can ask for an async GC and get a callback when it's done.
2249         
2250         Also adds ability to request that fastMalloc memory be released after the incremental
2251         sweeper finishes.
2252         
2253         * API/JSBase.cpp:
2254         (JSSynchronousGarbageCollectForDebugging):
2255         * CMakeLists.txt:
2256         * JavaScriptCore.xcodeproj/project.pbxproj:
2257         * heap/FullGCActivityCallback.cpp:
2258         (JSC::FullGCActivityCallback::doCollection):
2259         * heap/FullGCActivityCallback.h:
2260         * heap/GCRequest.cpp: Added.
2261         (JSC::GCRequest::subsumedBy):
2262         (JSC::GCRequest::dump):
2263         * heap/GCRequest.h: Added.
2264         (JSC::GCRequest::GCRequest):
2265         * heap/Heap.cpp:
2266         (JSC::Heap::collect):
2267         (JSC::Heap::collectNow):
2268         (JSC::Heap::collectAsync):
2269         (JSC::Heap::collectSync):
2270         (JSC::Heap::runBeginPhase):
2271         (JSC::Heap::runEndPhase):
2272         (JSC::Heap::requestCollection):
2273         (JSC::Heap::willStartCollection):
2274         (JSC::Heap::sweeper):
2275         (JSC::Heap::collectNowFullIfNotDoneRecently):
2276         (JSC::Heap::shouldDoFullCollection):
2277         (JSC::Heap::collectAllGarbage): Deleted.
2278         (JSC::Heap::collectAllGarbageIfNotDoneRecently): Deleted.
2279         * heap/Heap.h:
2280         * heap/HeapSnapshotBuilder.cpp:
2281         (JSC::HeapSnapshotBuilder::buildSnapshot):
2282         * heap/IncrementalSweeper.cpp:
2283         (JSC::IncrementalSweeper::doSweep):
2284         * heap/IncrementalSweeper.h:
2285         (JSC::IncrementalSweeper::freeFastMallocMemoryAfterSweeping):
2286         * heap/MarkedAllocator.cpp:
2287         (JSC::MarkedAllocator::doTestCollectionsIfNeeded):
2288         * heap/MarkedSpace.cpp:
2289         (JSC::MarkedSpace::sweep):
2290         * heap/Synchronousness.cpp: Added.
2291         (WTF::printInternal):
2292         * heap/Synchronousness.h: Added.
2293         * inspector/agents/InspectorHeapAgent.cpp:
2294         (Inspector::InspectorHeapAgent::gc):
2295         * jsc.cpp:
2296         (functionGCAndSweep):
2297         (runJSC):
2298         * tools/JSDollarVMPrototype.cpp:
2299         (JSC::JSDollarVMPrototype::gc):
2300         * wasm/WasmMemory.cpp:
2301
2302 2017-05-04  Mark Lam  <mark.lam@apple.com>
2303
2304         NeverDestroyed<String>(ASCIILiteral(...)) is not thread safe.
2305         https://bugs.webkit.org/show_bug.cgi?id=171586
2306         <rdar://problem/31873190>
2307
2308         Reviewed by Yusuke Suzuki.
2309
2310         JavaScriptCore allows multiple VMs to be instantiated, and each of these should
2311         be able to run concurrently on different threads.  There is code in the VM that
2312         allocates NeverDestroyed<String>(ASCIILiteral(...)) to defined immortal strings
2313         meant to be shared by all VMs.
2314
2315         However, NeverDestroyed<String>(ASCIILiteral(...)) is not thread-safe because
2316         each thread will ref and deref the underlying StringImpl.  Since this ref and
2317         deref is not done in a thread-safe way, the NeverDestroyed<String> may get
2318         destroyed due to the ref/deref races.  Additionally, each thread may modify the
2319         StringImpl by setting its hash and also twiddling its flags.
2320
2321         The fix is to use the StaticStringImpl class which is safe for ref/derefing
2322         concurrently from different threads.  StaticStringImpl is also pre-set with a
2323         hash on construction, and its flags are set in such a way as to prevent twiddling
2324         at runtime.  Hence, we will be able to share a NeverDestroyed<String> between
2325         VMs, as long as it is backed by a StaticStringImpl.
2326
2327         An alternative solution would be to change all the uses of NeverDestroyed<String>
2328         to use per-VM strings.  However, this solution is cumbersome, and makes it harder
2329         to allocate the intended shared string.  It also uses more memory and takes more
2330         CPU time because it requires allocating the same string for each VM instance.
2331         The StaticStringImpl solution wins out because it is more efficient and is easier
2332         to use.
2333
2334         The StaticStringImpl solution also can be used in WTF without a layer violation.
2335         See Source/WTF/wtf/text/icu/TextBreakIteratorICU.h for an example.
2336
2337         Also added the MultithreadedMultiVMExecutionTest which runs multiple VMs in
2338         multiple threads, all banging on the BuiltinExecutable's baseConstructorCode
2339         NeverDestroyed<String>.  The test will manifest the issue reliably (before this
2340         fix) if run on an ASAN build.
2341
2342         * API/tests/MultithreadedMultiVMExecutionTest.cpp: Added.
2343         (threadsList):
2344         (startMultithreadedMultiVMExecutionTest):
2345         (finalizeMultithreadedMultiVMExecutionTest):
2346         * API/tests/MultithreadedMultiVMExecutionTest.h: Added.
2347         * API/tests/testapi.c:
2348         (main):
2349         * JavaScriptCore.xcodeproj/project.pbxproj:
2350         * builtins/BuiltinExecutables.cpp:
2351         (JSC::BuiltinExecutables::createDefaultConstructor):
2352         * inspector/agents/InspectorDebuggerAgent.cpp:
2353         (Inspector::objectGroupForBreakpointAction):
2354         * replay/scripts/CodeGeneratorReplayInputsTemplates.py:
2355         * replay/scripts/tests/expected/generate-enum-encoding-helpers-with-guarded-values.json-TestReplayInputs.cpp:
2356         (JSC::InputTraits<Test::SavedMouseButton>::type):
2357         * replay/scripts/tests/expected/generate-enum-encoding-helpers.json-TestReplayInputs.cpp:
2358         (JSC::InputTraits<Test::SavedMouseButton>::type):
2359         * replay/scripts/tests/expected/generate-enum-with-guard.json-TestReplayInputs.cpp:
2360         (JSC::InputTraits<Test::HandleWheelEvent>::type):
2361         * replay/scripts/tests/expected/generate-enums-with-same-base-name.json-TestReplayInputs.cpp:
2362         (JSC::InputTraits<Test::FormCombo>::type):
2363         * replay/scripts/tests/expected/generate-input-with-guard.json-TestReplayInputs.cpp:
2364         (JSC::InputTraits<Test::GetCurrentTime>::type):
2365         (JSC::InputTraits<Test::SetRandomSeed>::type):
2366         * replay/scripts/tests/expected/generate-input-with-vector-members.json-TestReplayInputs.cpp:
2367         (JSC::InputTraits<Test::ArrayOfThings>::type):
2368         (JSC::InputTraits<Test::SavedHistory>::type):
2369         * replay/scripts/tests/expected/generate-inputs-with-flags.json-TestReplayInputs.cpp:
2370         (JSC::InputTraits<Test::ScalarInput1>::type):
2371         (JSC::InputTraits<Test::ScalarInput2>::type):
2372         * replay/scripts/tests/expected/generate-memoized-type-modes.json-TestReplayInputs.cpp:
2373         (JSC::InputTraits<Test::ScalarInput>::type):
2374         (JSC::InputTraits<Test::MapInput>::type):
2375         * runtime/IntlObject.cpp:
2376         (JSC::numberingSystemsForLocale):
2377
2378 2017-05-04  Sam Weinig  <sam@webkit.org>
2379
2380         Remove support for legacy Notifications
2381         https://bugs.webkit.org/show_bug.cgi?id=171487
2382
2383         Reviewed by Jon Lee.
2384
2385         * Configurations/FeatureDefines.xcconfig:
2386         Remove definition of ENABLE_LEGACY_NOTIFICATIONS.
2387
2388 2017-05-04  Konstantin Tokarev  <annulen@yandex.ru>
2389
2390         Fix compilation with ICU 59.1
2391         https://bugs.webkit.org/show_bug.cgi?id=171612
2392
2393         Reviewed by Mark Lam.
2394
2395         ICU 59.1 has broken source compatibility. Now it defines UChar as
2396         char16_t, which does not allow automatic type conversion from unsigned
2397         short in C++ code.
2398
2399         * API/JSStringRef.cpp:
2400         (JSStringCreateWithCharacters):
2401         (JSStringCreateWithCharactersNoCopy):
2402         (JSStringGetCharactersPtr):
2403         * runtime/DateConversion.cpp:
2404         (JSC::formatDateTime):
2405
2406 2017-05-04  Saam Barati  <sbarati@apple.com>
2407
2408         stress/call-apply-exponential-bytecode-size.js.no-llint failing on 32-bit debug for OOM on executable memory
2409         https://bugs.webkit.org/show_bug.cgi?id=171008
2410
2411         Reviewed by Yusuke Suzuki.
2412
2413         This patch lowers the threshold for .call/.apply recursion
2414         in an attempt to emit less code and not impact perf.
2415         We're currently failing tests on x86-32 by running out
2416         of executable memory. If perf gets impacted because of this,
2417         then I'll apply a stricter change just to 32-bit platforms.
2418         However, if this doesn't negatively impact perf, it's all around
2419         better than all platforms emit less bytecode.
2420
2421         * bytecompiler/NodesCodegen.cpp:
2422
2423 2017-05-04  Yusuke Suzuki  <utatane.tea@gmail.com>
2424
2425         [JSC] Math unary functions should be handled by DFG
2426         https://bugs.webkit.org/show_bug.cgi?id=171269
2427
2428         Reviewed by Saam Barati.
2429
2430         ArithSin, ArithCos, and ArithLog are just calling a C runtime function.
2431         While handling them in DFG is not very effective for performance, they
2432         can drop some type checks & value conversions and mark them as pure
2433         operations. It is effective if they are involved in some complex
2434         optimization phase. Actually, ArithLog is effective in kraken.
2435
2436         While a few of Math functions have DFG nodes, basically math functions
2437         are pure. And large part of these functions are just calling a C runtime
2438         function. This patch generalizes these nodes in DFG as ArithUnary. And
2439         we annotate many unary math functions with Intrinsics and convert them
2440         to ArithUnary in DFG. It also cleans up duplicate code in ArithSin,
2441         ArithCos, and ArithLog. If your math function has some good DFG / FTL
2442         optimization rather than calling a C runtime function, you should add
2443         a specialized DFG node, like ArithSqrt.
2444
2445         We also create a new namespace JSC::Math. Inside it, we collect math functions.
2446
2447         * dfg/DFGAbstractInterpreterInlines.h:
2448         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2449         * dfg/DFGArithMode.cpp:
2450         (JSC::DFG::arithUnaryFunction):
2451         (JSC::DFG::arithUnaryOperation):
2452         (WTF::printInternal):
2453         * dfg/DFGArithMode.h:
2454         * dfg/DFGBackwardsPropagationPhase.cpp:
2455         (JSC::DFG::BackwardsPropagationPhase::propagate):
2456         * dfg/DFGByteCodeParser.cpp:
2457         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
2458         * dfg/DFGClobberize.h:
2459         (JSC::DFG::clobberize):
2460         * dfg/DFGDoesGC.cpp:
2461         (JSC::DFG::doesGC):
2462         * dfg/DFGFixupPhase.cpp:
2463         (JSC::DFG::FixupPhase::fixupNode):
2464         * dfg/DFGGraph.cpp:
2465         (JSC::DFG::Graph::dump):
2466         * dfg/DFGNode.h:
2467         (JSC::DFG::Node::hasArithUnaryType):
2468         (JSC::DFG::Node::arithUnaryType):
2469         * dfg/DFGNodeType.h:
2470         * dfg/DFGOperations.cpp:
2471         * dfg/DFGOperations.h:
2472         * dfg/DFGPredictionPropagationPhase.cpp:
2473         * dfg/DFGSafeToExecute.h:
2474         (JSC::DFG::safeToExecute):
2475         * dfg/DFGSpeculativeJIT.cpp:
2476         (JSC::DFG::SpeculativeJIT::compileArithUnary):
2477         (JSC::DFG::SpeculativeJIT::compileArithCos): Deleted.
2478         (JSC::DFG::SpeculativeJIT::compileArithTan): Deleted.
2479         (JSC::DFG::SpeculativeJIT::compileArithSin): Deleted.
2480         (JSC::DFG::SpeculativeJIT::compileArithLog): Deleted.
2481         * dfg/DFGSpeculativeJIT.h:
2482         * dfg/DFGSpeculativeJIT32_64.cpp:
2483         (JSC::DFG::SpeculativeJIT::compile):
2484         * dfg/DFGSpeculativeJIT64.cpp:
2485         (JSC::DFG::SpeculativeJIT::compile):
2486         * ftl/FTLCapabilities.cpp:
2487         (JSC::FTL::canCompile):
2488         * ftl/FTLLowerDFGToB3.cpp:
2489         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2490         (JSC::FTL::DFG::LowerDFGToB3::compileArithUnary):
2491         (JSC::FTL::DFG::LowerDFGToB3::compileArithSin): Deleted.
2492         (JSC::FTL::DFG::LowerDFGToB3::compileArithCos): Deleted.
2493         (JSC::FTL::DFG::LowerDFGToB3::compileArithTan): Deleted.
2494         (JSC::FTL::DFG::LowerDFGToB3::compileArithLog): Deleted.
2495         * ftl/FTLOutput.cpp:
2496         (JSC::FTL::Output::doubleUnary):
2497         (JSC::FTL::Output::doubleSin): Deleted.
2498         (JSC::FTL::Output::doubleCos): Deleted.
2499         (JSC::FTL::Output::doubleTan): Deleted.
2500         (JSC::FTL::Output::doubleLog): Deleted.
2501         * ftl/FTLOutput.h:
2502         * runtime/Intrinsic.h:
2503         * runtime/MathCommon.cpp:
2504         (JSC::Math::log1p):
2505         * runtime/MathCommon.h:
2506         * runtime/MathObject.cpp:
2507         (JSC::MathObject::finishCreation):
2508         (JSC::mathProtoFuncACos):
2509         (JSC::mathProtoFuncASin):
2510         (JSC::mathProtoFuncATan):
2511         (JSC::mathProtoFuncCos):
2512         (JSC::mathProtoFuncExp):
2513         (JSC::mathProtoFuncLog):
2514         (JSC::mathProtoFuncSin):
2515         (JSC::mathProtoFuncTan):
2516         (JSC::mathProtoFuncACosh):
2517         (JSC::mathProtoFuncASinh):
2518         (JSC::mathProtoFuncATanh):
2519         (JSC::mathProtoFuncCbrt):
2520         (JSC::mathProtoFuncCosh):
2521         (JSC::mathProtoFuncExpm1):
2522         (JSC::mathProtoFuncLog1p):
2523         (JSC::mathProtoFuncLog10):
2524         (JSC::mathProtoFuncLog2):
2525         (JSC::mathProtoFuncSinh):
2526         (JSC::mathProtoFuncTanh):
2527
2528 2017-05-03  Saam Barati  <sbarati@apple.com>
2529
2530         How we build polymorphic cases is wrong when making a call from Wasm
2531         https://bugs.webkit.org/show_bug.cgi?id=171527
2532
2533         Reviewed by JF Bastien.
2534
2535         This patches fixes a bug when we emit a polymorphic call IC from
2536         Wasm. We were incorrectly assuming that if we made a call *from wasm*,
2537         then the thing we are *calling to* does not have a CodeBlock. This
2538         is obviously wrong. This patch fixes the incorrect assumption.
2539         
2540         This patch also does two more things:
2541         1. Add a new option that makes us make calls to JS using a
2542         slow path instead of using a call IC.
2543         2. Fixes a potential GC bug where we didn't populate JSWebAssemblyCodeBlock's
2544         JSWebAssemblyModule pointer.
2545
2546         * jit/Repatch.cpp:
2547         (JSC::linkPolymorphicCall):
2548         * runtime/Options.h:
2549         * wasm/WasmBinding.cpp:
2550         (JSC::Wasm::wasmToJs):
2551         * wasm/js/JSWebAssemblyCodeBlock.cpp:
2552         (JSC::JSWebAssemblyCodeBlock::create):
2553         (JSC::JSWebAssemblyCodeBlock::finishCreation):
2554         * wasm/js/JSWebAssemblyCodeBlock.h:
2555         * wasm/js/JSWebAssemblyInstance.cpp:
2556         (JSC::JSWebAssemblyInstance::finalizeCreation):
2557
2558 2017-05-03  Keith Miller  <keith_miller@apple.com>
2559
2560         Array.prototype.sort should also allow a null comparator
2561         https://bugs.webkit.org/show_bug.cgi?id=171621
2562         <rdar://problem/30757933>
2563
2564         Reviewed by Michael Saboff.
2565
2566         It looks like sort not accepting a null comparator
2567         causes some pages to stop working. Those pages work in
2568         Chrome/Firefox so we should try to match them.
2569
2570         * builtins/ArrayPrototype.js:
2571         (sort):
2572
2573 2017-05-03  Mark Lam  <mark.lam@apple.com>
2574
2575         Use the CLoop for CPU(ARM64E).
2576         https://bugs.webkit.org/show_bug.cgi?id=171620
2577         <rdar://problem/31973027>
2578
2579         Reviewed by Geoffrey Garen.
2580
2581         * llint/LLIntOfflineAsmConfig.h:
2582         * tools/SigillCrashAnalyzer.cpp:
2583         (JSC::SigillCrashAnalyzer::dumpCodeBlock):
2584
2585 2017-05-03  Keith Miller  <keith_miller@apple.com>
2586
2587         Different behaviour with the .sort(callback) method (unlike Firefox & Chrome)
2588         https://bugs.webkit.org/show_bug.cgi?id=47825
2589
2590         Reviewed by Saam Barati.
2591
2592         This patch makes our sort function match the behavior of Firefox
2593         and Chrome when the result of the comparison function is a
2594         boolean. When we first switched to using merge sort, it regressed
2595         JQuery sorting of DOM nodes by 30%. The regression was do to the
2596         fact that JQuery was using compareDocumentPosition to compare the
2597         locations of objects. Since one of the benchmarks would pass a
2598         reverse sorted list to the sort function we would end up walking
2599         the entire DOM to do comparisons. The solution to this was to
2600         merge based on comparison(right, left) rather than
2601         comparison(left, right). Although, in practice this does nothing
2602         since sort could just as easily receive an already sorted list and
2603         we're back in the same spot.
2604
2605         The downside of sorting with comparison(right, left) is that to
2606         maintain stability when sorting, you only want to merge from right
2607         when the comparison function returns a negative value. This is
2608         where the problem with booleans comes in. Since booleans toNumber
2609         false to 0 and true to 1 both values are "equal". This patch fixes
2610         this by special casing boolean return values.
2611
2612
2613         * builtins/ArrayPrototype.js:
2614         (sort.merge):
2615
2616 2017-05-03  Andy VanWagoner  <thetalecrafter@gmail.com>
2617
2618         [INTL] Support dashed values in unicode locale extensions
2619         https://bugs.webkit.org/show_bug.cgi?id=171480
2620
2621         Reviewed by JF Bastien.
2622
2623         Implements the UnicodeExtensionSubtags operation and updates the ResolveLocale operation to use it.
2624         This fixes locale extensions with values that include '-'. The following calendars work now:
2625         ethiopic-amete-alem
2626         islamic-umalqura
2627         islamic-tbla
2628         islamic-civil
2629         islamic-rgsa
2630
2631         While updating IntlObject, the comments containing spec text were replaced with a single url at the
2632         top of each function pointing to the relevant part of ECMA-402.
2633
2634         * runtime/IntlObject.cpp:
2635         (JSC::unicodeExtensionSubTags): Added.
2636         (JSC::resolveLocale): Updated to latest standard.
2637
2638 2017-05-02  Don Olmstead  <don.olmstead@am.sony.com>
2639
2640         Build fix after r216078
2641         https://bugs.webkit.org/show_bug.cgi?id=171554
2642
2643         Reviewed by Saam Barati.
2644
2645         * API/tests/testapi.c:
2646
2647 2017-05-02  Filip Pizlo  <fpizlo@apple.com>
2648
2649         Unreviewed, fix pedantic C compilers.
2650
2651         * API/tests/testapi.c:
2652         (markingConstraint):
2653         (testMarkingConstraints):
2654
2655 2017-05-02  Filip Pizlo  <fpizlo@apple.com>
2656
2657         Unreviewed, fix cmake build.
2658
2659         * CMakeLists.txt:
2660
2661 2017-05-02  Filip Pizlo  <fpizlo@apple.com>
2662
2663         JSC C API should expose GC marking constraints and weak references
2664         https://bugs.webkit.org/show_bug.cgi?id=171554
2665
2666         Reviewed by Geoffrey Garen.
2667         
2668         This exposes an API that lets you participate in the GC's fixpoint. You can ask the GC
2669         what is marked and you can tell the GC to mark things. The constraint callback cannot
2670         do a whole lot, but it can query marking state and it can dereference weak references.
2671         
2672         Additionally, this exposes a very simple weak reference API in C.
2673
2674         * API/JSMarkingConstraintPrivate.cpp: Added.
2675         (JSC::isMarked):
2676         (JSC::mark):
2677         (JSContextGroupRegisterMarkingConstraint):
2678         * API/JSMarkingConstraintPrivate.h: Added.
2679         * API/JSWeakPrivate.cpp: Added.
2680         (OpaqueJSWeak::OpaqueJSWeak):
2681         (JSWeakCreate):
2682         (JSWeakRetain):
2683         (JSWeakRelease):
2684         (JSWeakGetObject):
2685         * API/JSWeakPrivate.h: Added.
2686         * API/tests/testapi.c:
2687         (markingConstraint):
2688         (testMarkingConstraints):
2689         (main):
2690         * JavaScriptCore.xcodeproj/project.pbxproj:
2691         * heap/SlotVisitor.h:
2692         * heap/SlotVisitorInlines.h:
2693         (JSC::SlotVisitor::appendHiddenUnbarriered):
2694         (JSC::SlotVisitor::appendHidden):
2695
2696 2017-05-02  Mark Lam  <mark.lam@apple.com>
2697
2698         JSFixedArray::allocationSize() should not allow for allocation failure.
2699         https://bugs.webkit.org/show_bug.cgi?id=171516
2700
2701         Reviewed by Geoffrey Garen.
2702
2703         Since JSFixedArray::createFromArray() now handles allocation failures by throwing
2704         OutOfMemoryErrors, its helper function allocationSize() (which computes the buffer
2705         size to allocate) should also allow for allocation failure on overflow.
2706
2707         This issue is covered by the stress/js-fixed-array-out-of-memory.js test when
2708         run on 32-bit builds.
2709
2710         * runtime/JSFixedArray.h:
2711         (JSC::JSFixedArray::tryCreate):
2712         (JSC::JSFixedArray::allocationSize):
2713
2714 2017-05-01  Zan Dobersek  <zdobersek@igalia.com>
2715
2716         [aarch64][Linux] m_allowScratchRegister assert hit in MacroAssemblerARM64 under B3::Air::CCallSpecial::generate()
2717         https://bugs.webkit.org/show_bug.cgi?id=170672
2718
2719         Reviewed by Filip Pizlo.
2720
2721         In Air::CCallSpecial::admitsStack() we reject admitting the callee argument on
2722         the stack for ARM64 because that can lead to disallowed usage of the scratch
2723         register in MacroAssemblerARM64 when generating a call with an address Arg
2724         in Air::CCallSpecial::generate().
2725
2726         The testLinearScanWithCalleeOnStack test is added to testb3. It reproduces the
2727         original issue by force-spilling everything on the stack and enforcing the use
2728         of the linear scan register allocation by using an optimization level of 1.
2729
2730         * b3/air/AirCCallSpecial.cpp:
2731         (JSC::B3::Air::CCallSpecial::admitsStack):
2732         * b3/testb3.cpp:
2733         (JSC::B3::testLinearScanWithCalleeOnStack):
2734         (JSC::B3::run):
2735
2736 2017-05-01  David Kilzer  <ddkilzer@apple.com>
2737
2738         Stop using sprintf() in JavaScriptCore debugger
2739         <https://webkit.org/b/171512>
2740
2741         Reviewed by Keith Miller.
2742
2743         * disassembler/udis86/udis86.c:
2744         (ud_insn_hex): Switch from sprintf() to snprintf().
2745
2746 2017-04-21  Filip Pizlo  <fpizlo@apple.com>
2747
2748         Air::fixObviousSpills should remove totally redundant instructions
2749         https://bugs.webkit.org/show_bug.cgi?id=171131
2750
2751         Reviewed by Saam Barati.
2752         
2753         This is a modest compile-time-neutral improvement to fixObviousSpills. That phase
2754         builds up a classic alias analysis data structure over spills and registers and then
2755         uses it to remove the most common spill pathologies we encounter. For example, if you
2756         use a spill but the spill is aliased to a register or constant, then we can replace the
2757         use of the spill with a use of the register or constant.
2758         
2759         But that phase was missing perhaps one of the most obvious fixups that its analysis
2760         allows us to do: if any instruction creates an alias we already know about, then the
2761         instruction is redundant. This turned out to be super important for
2762         https://bugs.webkit.org/show_bug.cgi?id=171075. That patch didn't work out, but this
2763         kind of optimization might be a good clean-up for many other kinds of optimizations.
2764
2765         * b3/air/AirFixObviousSpills.cpp:
2766
2767 2017-04-30  Oleksandr Skachkov  <gskachkov@gmail.com>
2768
2769         We initialize functions too early in an eval
2770         https://bugs.webkit.org/show_bug.cgi?id=161099
2771
2772         Reviewed by Saam Barati.
2773
2774         Current patch allow to fix problem with scope in function that is 
2775         declared within eval. Before scope was set inside Interpretator.cpp and it
2776         was scope where eval is executed, but in this case function would not 
2777         see let/const variables and classes declated in eval.
2778         This patch devide declaration and binding in two operation, first just declare
2779         variable with function name, and second bind variable to function with correct 
2780         scope
2781
2782         * bytecompiler/BytecodeGenerator.cpp:
2783         (JSC::BytecodeGenerator::generate):
2784         (JSC::BytecodeGenerator::BytecodeGenerator):
2785         * bytecompiler/BytecodeGenerator.h:
2786         * interpreter/Interpreter.cpp:
2787         (JSC::Interpreter::execute):
2788
2789 2017-04-30  Oleksandr Skachkov  <gskachkov@gmail.com>
2790
2791         [ES6]. Implement Annex B.3.3 function hoisting rules for eval
2792         https://bugs.webkit.org/show_bug.cgi?id=163208
2793
2794         Reviewed by Saam Barati.
2795
2796         Current patch implements Annex B.3.3 that is related to 
2797         hoisting of function declaration in eval. 
2798         https://tc39.github.io/ecma262/#sec-web-compat-evaldeclarationinstantiation
2799         Function declaration in eval should create variable with 
2800         function name in function scope where eval is invoked 
2801         or bind to variable if it declared outside of the eval. 
2802         If variable is created it can be removed by 'delete a;' command. 
2803         If eval is invoke in block scope that contains let/const 
2804         variable with the same name as function declaration 
2805         we do not bind. This patch leads to the following behavior: 
2806         '''
2807         function foo() {
2808            {
2809              print(boo); // undefined
2810              eval('{ function boo() {}}');
2811              print(boo); // function boo() {}
2812            }
2813            print(boo); // function boo() {}
2814         }
2815
2816         function foobar() {
2817           { 
2818             let boo = 10;
2819             print(boo); // 10;
2820             eval('{ function boo() {}}');
2821             print(boo); // 10;
2822           }
2823           print(boo) // 10
2824         }
2825
2826         function bar() {
2827            {
2828               var boo = 10;
2829               print(boo); // 10
2830               eval('{ function boo() {} }'); 
2831               print(boo); // function boo() {}
2832            }
2833            print(boo); // function boo() {}
2834         }       
2835         
2836         function bas() {
2837             {
2838                  let boo = 10;
2839                  eval(' { function boo() {} } ');
2840                  print(boo); // 10
2841             }
2842             print(boo); //Reference Error
2843         }
2844         '''
2845
2846         Current implementation relies on already implemented 
2847         'hoist function in sloppy mode' feature, with small changes.
2848         In short it works in following way: during hoisting of function 
2849         with name S in eval, we are looking for first scope that 
2850         contains space for variable with name S and if this scope 
2851         has var type we bind function there
2852
2853         To implement this feature was added bytecode ops:
2854         op_resolve_scope_for_hoisting_func_decl_in_eval - get variable scope 
2855         or return undefined if variable can't be binded there.
2856
2857         There is a corner case, hoist function in eval within catch block,
2858         that is not covered by this patch, and will be fixed in 
2859         https://bugs.webkit.org/show_bug.cgi?id=168184
2860
2861         * bytecode/BytecodeDumper.cpp:
2862         (JSC::BytecodeDumper<Block>::dumpBytecode):
2863         * bytecode/BytecodeList.json:
2864         * bytecode/BytecodeUseDef.h:
2865         (JSC::computeUsesForBytecodeOffset):
2866         (JSC::computeDefsForBytecodeOffset):
2867         * bytecode/CodeBlock.cpp:
2868         (JSC::CodeBlock::finalizeLLIntInlineCaches):
2869         * bytecode/EvalCodeBlock.h:
2870         (JSC::EvalCodeBlock::functionHoistingCandidate):
2871         (JSC::EvalCodeBlock::numFunctionHoistingCandidates):
2872         * bytecode/UnlinkedEvalCodeBlock.h:
2873         * bytecompiler/BytecodeGenerator.cpp:
2874         (JSC::BytecodeGenerator::BytecodeGenerator):
2875         (JSC::BytecodeGenerator::hoistSloppyModeFunctionIfNecessary):
2876         (JSC::BytecodeGenerator::emitResolveScopeForHoistingFuncDeclInEval):
2877         * bytecompiler/BytecodeGenerator.h:
2878         * dfg/DFGAbstractInterpreterInlines.h:
2879         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2880         * dfg/DFGByteCodeParser.cpp:
2881         (JSC::DFG::ByteCodeParser::parseBlock):
2882         * dfg/DFGCapabilities.cpp:
2883         (JSC::DFG::capabilityLevel):
2884         * dfg/DFGClobberize.h:
2885         (JSC::DFG::clobberize):
2886         * dfg/DFGDoesGC.cpp:
2887         (JSC::DFG::doesGC):
2888         * dfg/DFGFixupPhase.cpp:
2889         (JSC::DFG::FixupPhase::fixupNode):
2890         * dfg/DFGNode.h:
2891         (JSC::DFG::Node::hasIdentifier):
2892         * dfg/DFGNodeType.h:
2893         * dfg/DFGOperations.cpp:
2894         * dfg/DFGOperations.h:
2895         * dfg/DFGPredictionPropagationPhase.cpp:
2896         * dfg/DFGSafeToExecute.h:
2897         (JSC::DFG::safeToExecute):
2898         * dfg/DFGSpeculativeJIT.cpp:
2899         (JSC::DFG::SpeculativeJIT::compileResolveScopeForHoistingFuncDeclInEval):
2900         * dfg/DFGSpeculativeJIT.h:
2901         (JSC::DFG::SpeculativeJIT::callOperation):
2902         * dfg/DFGSpeculativeJIT32_64.cpp:
2903         (JSC::DFG::SpeculativeJIT::compile):
2904         * dfg/DFGSpeculativeJIT64.cpp:
2905         (JSC::DFG::SpeculativeJIT::compile):
2906         * ftl/FTLCapabilities.cpp:
2907         (JSC::FTL::canCompile):
2908         * ftl/FTLLowerDFGToB3.cpp:
2909         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2910         (JSC::FTL::DFG::LowerDFGToB3::compileResolveScopeForHoistingFuncDeclInEval):
2911         * interpreter/Interpreter.cpp:
2912         (JSC::Interpreter::execute):
2913         * jit/JIT.cpp:
2914         (JSC::JIT::privateCompileMainPass):
2915         * jit/JIT.h:
2916         * jit/JITOperations.h:
2917         * jit/JITPropertyAccess.cpp:
2918         (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval):
2919         * jit/JITPropertyAccess32_64.cpp:
2920         (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval):
2921         * llint/LowLevelInterpreter.asm:
2922         * parser/Parser.cpp:
2923         (JSC::Parser<LexerType>::parseFunctionDeclarationStatement):
2924         * parser/Parser.h:
2925         (JSC::Scope::getSloppyModeHoistedFunctions):
2926         (JSC::Parser::declareFunction):
2927         * runtime/CommonSlowPaths.cpp:
2928         (JSC::SLOW_PATH_DECL):
2929         * runtime/CommonSlowPaths.h:
2930         * runtime/EvalExecutable.h:
2931         (JSC::EvalExecutable::numFunctionHoistingCandidates):
2932         (JSC::EvalExecutable::numTopLevelFunctionDecls):
2933         (JSC::EvalExecutable::numberOfFunctionDecls): Deleted.
2934         * runtime/JSScope.cpp:
2935         (JSC::JSScope::resolve):
2936         (JSC::JSScope::resolveScopeForHoistingFuncDeclInEval):
2937         * runtime/JSScope.h:
2938
2939 2017-04-29  Oleksandr Skachkov  <gskachkov@gmail.com>
2940
2941         Deep nesting is leading to ReferenceError for hoisted function
2942         https://bugs.webkit.org/show_bug.cgi?id=171456
2943
2944         Reviewed by Yusuke Suzuki.
2945
2946         Current patch fix error that appears during hoisting of the function 
2947         in block scope. Error happens only when exist some deep scope that lead
2948         to increase scope stack, after which list of the hosted candidates do not 
2949         copied to updated scope stack.
2950
2951         * parser/Parser.h:
2952         (JSC::Scope::Scope):
2953
2954 2017-04-29  Yusuke Suzuki  <utatane.tea@gmail.com>
2955
2956         [JSC] LabelScopePtr is not necessary
2957         https://bugs.webkit.org/show_bug.cgi?id=171474
2958
2959         Reviewed by Geoffrey Garen.
2960
2961         Originally, LabelScopePtr is introduced because LabelScopes uses Vector<> instead of SegmentedVector<>.
2962         LabelScopePtr holds the pointer to the vector owner and index instead of the pointer to LabelScope directly
2963         since Vector<> can relocate LocalScopes inside it.
2964         The reason why LabelScopes use Vector instead is that there is code copying this vector. SegmentedVector<>
2965         prohibits copying since it is so costly. So, we used Vector<> here instead of SegmentedVector<>.
2966
2967         But the latest code does not have copying code for LabelScopes. Thus, we can take the same design to Label and
2968         RegisterID. Just use SegmentedVector<> and Ref<>/RefPtr<>. This patch removes LabelScopePtr since it is no
2969         longer necessary. And use SegmentedVector for LabelScopes.
2970
2971         * bytecompiler/BytecodeGenerator.cpp:
2972         (JSC::reclaim):
2973         (JSC::BytecodeGenerator::reclaimFreeRegisters):
2974         (JSC::BytecodeGenerator::newLabelScope):
2975         (JSC::BytecodeGenerator::newLabel):
2976         (JSC::BytecodeGenerator::pushFinallyControlFlowScope):
2977         (JSC::BytecodeGenerator::breakTarget):
2978         (JSC::BytecodeGenerator::continueTarget):
2979         (JSC::BytecodeGenerator::emitEnumeration):
2980         * bytecompiler/BytecodeGenerator.h:
2981         * bytecompiler/LabelScope.h:
2982         (JSC::LabelScope::LabelScope):
2983         (JSC::LabelScope::breakTarget):
2984         (JSC::LabelScope::continueTarget):
2985         (JSC::LabelScope::type):
2986         (JSC::LabelScope::name):
2987         (JSC::LabelScope::scopeDepth):
2988         (JSC::LabelScope::ref):
2989         (JSC::LabelScope::deref):
2990         (JSC::LabelScope::refCount):
2991         (JSC::LabelScopePtr::LabelScopePtr): Deleted.
2992         (JSC::LabelScopePtr::operator=): Deleted.
2993         (JSC::LabelScopePtr::~LabelScopePtr): Deleted.
2994         (JSC::LabelScopePtr::operator!): Deleted.
2995         (JSC::LabelScopePtr::operator*): Deleted.
2996         (JSC::LabelScopePtr::operator->): Deleted.
2997         (JSC::LabelScopePtr::null): Deleted.
2998         * bytecompiler/NodesCodegen.cpp:
2999         (JSC::DoWhileNode::emitBytecode):
3000         (JSC::WhileNode::emitBytecode):
3001         (JSC::ForNode::emitBytecode):
3002         (JSC::ForInNode::emitBytecode):
3003         (JSC::ContinueNode::trivialTarget):
3004         (JSC::ContinueNode::emitBytecode):
3005         (JSC::BreakNode::trivialTarget):
3006         (JSC::BreakNode::emitBytecode):
3007         (JSC::SwitchNode::emitBytecode):
3008         (JSC::LabelNode::emitBytecode):
3009
3010 2017-04-28  Mark Lam  <mark.lam@apple.com>
3011
3012         Revert instrumentation from https://bugs.webkit.org/show_bug.cgi?id=170086 that is no longer needed.
3013         https://bugs.webkit.org/show_bug.cgi?id=170094
3014
3015         Reviewed by JF Bastien and Keith Miller.
3016
3017         * heap/Heap.cpp:
3018         (JSC::Heap::resumeThePeriphery):
3019
3020 2017-04-27  Andy VanWagoner  <thetalecrafter@gmail.com>
3021
3022         [INTL] Implement the caseFirst option for Intl.Collator
3023         https://bugs.webkit.org/show_bug.cgi?id=158188
3024
3025         Reviewed by Geoffrey Garen.
3026
3027         Implements the caseFirst option and unicode locale extension.
3028         The caseFirst option explicitly determines whether upper or lower case comes first.
3029
3030         * runtime/IntlCollator.cpp:
3031         (JSC::sortLocaleData): Added kf data.
3032         (JSC::searchLocaleData): Added kf data.
3033         (JSC::IntlCollator::initializeCollator): Set caseFirst option.
3034         (JSC::IntlCollator::createCollator): Set new attributes on ICU collator.
3035         (JSC::IntlCollator::caseFirstString): Added.
3036         (JSC::IntlCollator::resolvedOptions): Added caseFirst property.
3037         * runtime/IntlCollator.h:
3038
3039 2017-04-27  Mark Lam  <mark.lam@apple.com>
3040
3041         Fix some RELEASE_ASSERT failures caused by OutOfMemoryErrors.
3042         https://bugs.webkit.org/show_bug.cgi?id=171404
3043         <rdar://problem/31876178>
3044
3045         Reviewed by Saam Barati.
3046
3047         1. Added some tryAllocate() functions in JSCellInlines.h.
3048         2. Consolidated the implementations of allocateCell() template functions into a
3049            single tryAllocateCellHelper() to reduce redundancy and eliminate needing to
3050            copy-paste for variations of allocateCell and tryAllocateCell.
3051         3. Changed JSFixedArray::createFromArray() and constructEmptyArray() to check for
3052            allocation failure and throw an OutOfMemoryError.  It was already possible to
3053            throw errors from these functions for other reasons.  So, their clients are
3054            already ready to handle OOMEs.
3055
3056         * ftl/FTLOperations.cpp:
3057         (JSC::FTL::operationMaterializeObjectInOSR):
3058         * runtime/JSCInlines.h:
3059         * runtime/JSCell.h:
3060         * runtime/JSCellInlines.h:
3061         (JSC::tryAllocateCellHelper):
3062         (JSC::allocateCell):
3063         (JSC::tryAllocateCell):
3064         * runtime/JSFixedArray.h:
3065         (JSC::JSFixedArray::createFromArray):
3066         (JSC::JSFixedArray::tryCreate):
3067         (JSC::JSFixedArray::create): Deleted.
3068         * runtime/JSGlobalObject.h:
3069         (JSC::constructEmptyArray):
3070
3071 2017-04-27  Joseph Pecoraro  <pecoraro@apple.com>
3072
3073         Support for promise rejection events (unhandledrejection)
3074         https://bugs.webkit.org/show_bug.cgi?id=150358
3075         <rdar://problem/28441651>
3076
3077         Reviewed by Saam Barati.
3078
3079         Patch by Joseph Pecoraro and Yusuke Suzuki.
3080
3081         Implement support for promise.[[PromiseIsHandled]] and the
3082         HostPromiseRejectionTracker hook for HTML to track promise rejections:
3083         https://tc39.github.io/ecma262/#sec-host-promise-rejection-tracker
3084         https://html.spec.whatwg.org/multipage/webappapis.html#unhandled-promise-rejections
3085
3086         * builtins/BuiltinNames.h:
3087         New private symbols.
3088
3089         * builtins/PromiseOperations.js:
3090         (globalPrivate.newHandledRejectedPromise):
3091         Utility to create a rejected promise with [[PromiseIsHandled]] to true.
3092
3093         (globalPrivate.rejectPromise):
3094         (globalPrivate.initializePromise):
3095         * builtins/PromisePrototype.js:
3096         (then):
3097         Implement standard behavior of [[PromiseIsHandled]] and the host hook.
3098
3099         * runtime/JSPromise.cpp:
3100         (JSC::JSPromise::isHandled):
3101         * runtime/JSPromise.h:
3102         C++ accessors for the [[PromiseIsHandled]] state.
3103
3104         * bytecode/BytecodeIntrinsicRegistry.cpp:
3105         (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
3106         * bytecode/BytecodeIntrinsicRegistry.h:
3107         Expose private values for the Reject / Handle enum values in built-ins.
3108
3109         * jsc.cpp:
3110         * runtime/JSGlobalObject.h:
3111         (JSC::JSGlobalObject::promiseResolveFunction):
3112         Add a new GlobalObjectMethodTable hook matching the promise rejection hook.
3113
3114         * runtime/JSGlobalObject.cpp:
3115         (JSC::JSGlobalObject::init):
3116         (JSC::JSGlobalObject::visitChildren):
3117         * runtime/JSGlobalObjectFunctions.cpp:
3118         (JSC::globalFuncHostPromiseRejectionTracker):
3119         * runtime/JSGlobalObjectFunctions.h:
3120         Plumb the builtin hook through to the optional GlobalObjectMethodTable hook.
3121
3122         * inspector/InjectedScriptSource.js:
3123         (InjectedScript.prototype.createFakeValueDescriptor):
3124         Silence possible rejected promises created internally via Web Inspector.
3125
3126 2017-04-27  Saam Barati  <sbarati@apple.com>
3127
3128         B3::FoldPathConstants does not consider the fall through case for Switch
3129         https://bugs.webkit.org/show_bug.cgi?id=171390
3130
3131         Reviewed by Filip Pizlo.
3132
3133         foldPathConstants was not taking into account a Switch's default
3134         case when it tried to constant propagate the switch's operand value.
3135         e.g, we incorrectly transformed this code:
3136         
3137         ```
3138         x = argumentGPR0;
3139         switch (x) {
3140         case 10: return 20;
3141         
3142         case 0:
3143         default: return x == 0;
3144         }
3145         ```
3146         
3147         into:
3148         ```
3149         x = argumentGPR0;
3150         switch (x) {
3151         case 10: return 20;
3152         
3153         case 0:
3154         default: return 1;
3155         }
3156         ```
3157         
3158         Because we didn't take into account the default case, we incorrectly
3159         optimized the code as if case 0's block was only reachable if x is
3160         equal to zero. This is obviously not true, since it's the same block
3161         as the default case.
3162         
3163         This fix ensures that we can run the WebAssembly Tanks demo even when
3164         we set webAssemblyBBQOptimizationLevel=2.
3165
3166         * b3/B3FoldPathConstants.cpp:
3167         * b3/B3SwitchValue.cpp:
3168         (JSC::B3::SwitchValue::fallThrough):
3169         (JSC::B3::SwitchValue::removeCase): Deleted.
3170         * b3/B3SwitchValue.h:
3171         * b3/testb3.cpp:
3172         (JSC::B3::testCallFunctionWithHellaArguments):
3173         (JSC::B3::testSwitchSameCaseAsDefault):
3174         (JSC::B3::testWasmBoundsCheck):
3175         (JSC::B3::run):
3176
3177 2017-04-27  Keith Miller  <keith_miller@apple.com>
3178
3179         WebAssembly: Don't tier up the same function twice
3180         https://bugs.webkit.org/show_bug.cgi?id=171397
3181
3182         Reviewed by Filip Pizlo.
3183
3184         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:
3185
3186         Threads A and B are running count in memory is (0):
3187
3188         A: load tier up count (0)
3189         B: load tier up count (0)
3190         A: decrement count to -2 and see we need to check for tier up (0)
3191         A: store -2 to count (-2)
3192         A: exchangeOr(1) to tier up count (-1)
3193         B: decrement count to -2 and see we need to check for tier up (-1)
3194         B: store -2 to count (-2)
3195         B: exchangeOr(1) to tier up count (-1)
3196
3197         This would cause us to tier up the same function twice, which we would rather avoid.
3198
3199         * wasm/WasmB3IRGenerator.cpp:
3200         (JSC::Wasm::B3IRGenerator::emitTierUpCheck):
3201         * wasm/WasmTierUpCount.h:
3202         (JSC::Wasm::TierUpCount::TierUpCount):
3203         (JSC::Wasm::TierUpCount::loopDecrement):
3204         (JSC::Wasm::TierUpCount::functionEntryDecrement):
3205         (JSC::Wasm::TierUpCount::shouldStartTierUp):
3206
3207 2017-04-27  Keith Miller  <keith_miller@apple.com>
3208
3209         REGRESSION (r215843): ASSERTION FAILED: !m_completionTasks[0].first in  JSC::Wasm::Plan::tryRemoveVMAndCancelIfLast(JSC::VM &)
3210         https://bugs.webkit.org/show_bug.cgi?id=171380
3211
3212         Reviewed by JF Bastien.
3213
3214         This patch fixes the association of VMs to Wasm::Plans. For validation
3215         we want all the completion tasks to be associate with a VM. For BBQ,
3216         we want the main task to not be associated with any VM.
3217
3218         * jsc.cpp:
3219         (functionTestWasmModuleFunctions):
3220         * wasm/WasmBBQPlan.cpp:
3221         (JSC::Wasm::BBQPlan::BBQPlan):
3222         * wasm/WasmBBQPlan.h:
3223         * wasm/WasmCodeBlock.cpp:
3224         (JSC::Wasm::CodeBlock::CodeBlock):
3225         (JSC::Wasm::CodeBlock::compileAsync):
3226         * wasm/WasmCodeBlock.h:
3227         (JSC::Wasm::CodeBlock::create):
3228         * wasm/WasmModule.cpp:
3229         (JSC::Wasm::makeValidationCallback):
3230         (JSC::Wasm::Module::validateSync):
3231         (JSC::Wasm::Module::validateAsync):
3232         (JSC::Wasm::Module::getOrCreateCodeBlock):
3233         (JSC::Wasm::Module::compileSync):
3234         (JSC::Wasm::Module::compileAsync):
3235         * wasm/WasmModule.h:
3236         * wasm/WasmOMGPlan.cpp:
3237         (JSC::Wasm::OMGPlan::OMGPlan):
3238         (JSC::Wasm::runOMGPlanForIndex):
3239         * wasm/WasmOMGPlan.h:
3240         * wasm/WasmPlan.cpp:
3241         (JSC::Wasm::Plan::Plan):
3242         (JSC::Wasm::Plan::runCompletionTasks):
3243         (JSC::Wasm::Plan::addCompletionTask):
3244         (JSC::Wasm::Plan::tryRemoveVMAndCancelIfLast):
3245         * wasm/WasmPlan.h:
3246         (JSC::Wasm::Plan::dontFinalize):
3247         * wasm/js/WebAssemblyInstanceConstructor.cpp:
3248         (JSC::constructJSWebAssemblyInstance):
3249         * wasm/js/WebAssemblyPrototype.cpp:
3250         (JSC::webAssemblyValidateFunc):
3251
3252 2017-04-27  Saam Barati  <sbarati@apple.com>
3253
3254         Restore some caching functionality that got accidentally removed when doing Wasm PIC patches
3255         https://bugs.webkit.org/show_bug.cgi?id=171382
3256
3257         Reviewed by Keith Miller.
3258
3259         When I created Wasm::CodeBlock, I accidentally removed caching
3260         the creation of JSWebAssemblyCodeBlocks. This patch restores it.
3261         It's worth keeping JSWebAssemblyModule's JSWebAssemblyCodeBlock
3262         cache because creating a JSWebAssemblyCodeBlock does non trivial
3263         work by creating the various IC call stubs.
3264
3265         * wasm/js/JSWebAssemblyCodeBlock.h:
3266         (JSC::JSWebAssemblyCodeBlock::codeBlock):
3267         * wasm/js/JSWebAssemblyInstance.cpp:
3268         (JSC::JSWebAssemblyInstance::finalizeCreation):
3269         (JSC::JSWebAssemblyInstance::create):
3270         * wasm/js/JSWebAssemblyModule.h:
3271
3272 2017-04-27  Mark Lam  <mark.lam@apple.com>
3273
3274         Audit and fix incorrect uses of JSArray::tryCreateForInitializationPrivate().
3275         https://bugs.webkit.org/show_bug.cgi?id=171344
3276         <rdar://problem/31352667>
3277
3278         Reviewed by Filip Pizlo.
3279
3280         JSArray::tryCreateForInitializationPrivate() should only be used in performance
3281         critical paths, and should always be used with care because it creates an
3282         uninitialized object that needs to be initialized by its client before the object
3283         can be released into the system.  Before the object is fully initialized:
3284         a. the client should not re-enter the VM to execute JS code, and
3285         b. GC should not run.
3286
3287         This is because until the object is fully initialized, it is an inconsistent
3288         state that the GC and JS code will not be happy about.
3289
3290         In this patch, we do the following:
3291
3292         1. Renamed JSArray::tryCreateForInitializationPrivate() to
3293            JSArray::tryCreateUninitializedRestricted() because "private" is a bit ambiguous
3294            and can be confused with APIs that are called freely within WebKit but are
3295            not meant for clients of WebKit.  In this case, we intend for use of this API
3296            to be restricted to only a few carefully considered and crafted cases.
3297
3298         2. Introduce the ObjectInitializationScope RAII object which covers the period
3299            when the uninitialized object is created and gets initialized.
3300
3301            ObjectInitializationScope will asserts that either the object is created
3302            fully initialized (in the case where the object structure is not an "original"
3303            structure) or if created uninitialized, is fully initialized at the end of
3304            the scope.
3305
3306            If the object is created uninitialized, the ObjectInitializationScope also
3307            ensures that we do not GC nor re-enter the VM to execute JS code.  This is
3308            achieved by enabling DisallowGC and DisallowVMReentry scopes.
3309
3310            tryCreateUninitializedRestricted() and initializeIndex() now requires an
3311            ObjectInitializationScope instance.  The ObjectInitializationScope replaces
3312            the VM& argument because it can be used to pass the VM& itself.  This is a
3313            small optimization that makes passing the ObjectInitializationScope free even
3314            on release builds.
3315
3316         3. Factored a DisallowScope out of DisallowGC, and make DisallowGC extend it.
3317            Introduce a DisallowVMReentry class that extends DisallowScope.
3318
3319         4. Fixed a bug found by the ObjectInitializationScope.  The bug is that there are
3320            scenarios where the structure passed to tryCreateUninitializedRestricted()
3321            that may not be an "original" structure.  As a result, initializeIndex() would
3322            end up allocating new structures, and therefore trigger a GC.
3323
3324            The fix is to detect that the structure passed to tryCreateUninitializedRestricted()
3325            is not an "original" one, and pre-initialize the array with 0s.
3326
3327            This bug was detected by existing tests. Hence, no new test needed.
3328
3329         5. Replaced all inappropriate uses of tryCreateUninitializedRestricted() with
3330            tryCreate().  Inappropriate uses here means code that is not in performance
3331            critical paths.
3332
3333            Similarly, replaced accompanying uses of initializeIndex() with putDirectIndex().
3334
3335            This patch is performance neutral (according to the JSC command line benchmarks).
3336
3337         * CMakeLists.txt:
3338         * JavaScriptCore.xcodeproj/project.pbxproj:
3339         * dfg/DFGOperations.cpp:
3340         * ftl/FTLOperations.cpp:
3341         (JSC::FTL::operationMaterializeObjectInOSR):
3342         * heap/DeferGC.cpp:
3343         * heap/DeferGC.h:
3344         (JSC::DisallowGC::DisallowGC):
3345         (JSC::DisallowGC::initialize):
3346         (JSC::DisallowGC::scopeReentryCount):
3347         (JSC::DisallowGC::setScopeReentryCount):
3348         (JSC::DisallowGC::~DisallowGC): Deleted.
3349         (JSC::DisallowGC::isGCDisallowedOnCurrentThread): Deleted.
3350         * heap/GCDeferralContextInlines.h:
3351         (JSC::GCDeferralContext::~GCDeferralContext):
3352         * heap/Heap.cpp:
3353         (JSC::Heap::collectIfNecessaryOrDefer):
3354         * runtime/ArrayPrototype.cpp:
3355         (JSC::arrayProtoPrivateFuncConcatMemcpy):
3356         * runtime/ClonedArguments.cpp:
3357         (JSC::ClonedArguments::createWithInlineFrame):
3358         (JSC::ClonedArguments::createByCopyingFrom):
3359         * runtime/CommonSlowPaths.cpp:
3360         (JSC::SLOW_PATH_DECL):
3361         * runtime/DisallowScope.h: Added.
3362         (JSC::DisallowScope::DisallowScope):
3363         (JSC::DisallowScope::~DisallowScope):
3364         (JSC::DisallowScope::isInEffectOnCurrentThread):
3365         (JSC::DisallowScope::enable):
3366         (JSC::DisallowScope::enterScope):
3367         (JSC::DisallowScope::exitScope):
3368         * runtime/DisallowVMReentry.cpp: Added.
3369         * runtime/DisallowVMReentry.h: Added.
3370         (JSC::DisallowVMReentry::DisallowVMReentry):
3371         (JSC::DisallowVMReentry::initialize):
3372         (JSC::DisallowVMReentry::scopeReentryCount):
3373         (JSC::DisallowVMReentry::setScopeReentryCount):
3374    &nbs