FTL: Emit code to validate AI's state when running the compiled code
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2019-03-26  Saam Barati  <sbarati@apple.com>
2
3         FTL: Emit code to validate AI's state when running the compiled code
4         https://bugs.webkit.org/show_bug.cgi?id=195924
5         <rdar://problem/49003422>
6
7         Reviewed by Filip Pizlo.
8
9         This patch adds code that between the execution of each node that validates
10         the types that AI proves. This option is too expensive to turn on for our
11         regression testing, but we think it will be valuable in other types of running
12         modes, such as when running with a fuzzer.
13         
14         This patch also adds options to only probabilistically run this validation
15         after the execution of each node. As the probability is lowered, there is
16         less of a perf hit.
17         
18         This patch just adds this validation in the FTL. A follow-up patch will land
19         it in the DFG too: https://bugs.webkit.org/show_bug.cgi?id=196219
20
21         * ftl/FTLLowerDFGToB3.cpp:
22         (JSC::FTL::DFG::LowerDFGToB3::LowerDFGToB3):
23         (JSC::FTL::DFG::LowerDFGToB3::compileBlock):
24         (JSC::FTL::DFG::LowerDFGToB3::validateAIState):
25         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
26         (JSC::FTL::DFG::LowerDFGToB3::lowJSValue):
27         * runtime/Options.h:
28
29 2019-03-26  Tadeu Zagallo  <tzagallo@apple.com>
30
31         WebAssembly: Fix f32.min, f64.min and f64.max operations on NaN
32         https://bugs.webkit.org/show_bug.cgi?id=196217
33
34         Reviewed by Saam Barati.
35
36         Generalize the fix for f32.max to properly handle NaN by doing an extra GreatherThan
37         comparison in r243446 to all min and max float operations.
38
39         * wasm/WasmAirIRGenerator.cpp:
40         (JSC::Wasm::AirIRGenerator::addOp<OpType::F32Min>):
41         (JSC::Wasm::AirIRGenerator::addFloatingPointMinOrMax):
42         (JSC::Wasm::AirIRGenerator::addOp<OpType::F32Max>):
43         (JSC::Wasm::AirIRGenerator::addOp<OpType::F64Min>):
44         (JSC::Wasm::AirIRGenerator::addOp<OpType::F64Max>):
45         * wasm/wasm.json:
46
47 2019-03-26  Andy VanWagoner  <andy@vanwagoner.family>
48
49         Intl.DateTimeFormat should obey 2-digit hour
50         https://bugs.webkit.org/show_bug.cgi?id=195974
51
52         Reviewed by Keith Miller.
53
54         * runtime/IntlDateTimeFormat.cpp:
55         (JSC::IntlDateTimeFormat::initializeDateTimeFormat):
56
57 2019-03-25  Yusuke Suzuki  <ysuzuki@apple.com>
58
59         Heap::isMarked and friends should be instance methods
60         https://bugs.webkit.org/show_bug.cgi?id=179988
61
62         Reviewed by Saam Barati.
63
64         Almost all the callers of Heap::isMarked have VM& reference. We should make Heap::isMarked instance function instead of static function
65         so that we do not need to look up Heap from the cell.
66
67         * API/JSAPIWrapperObject.mm:
68         (JSAPIWrapperObjectHandleOwner::isReachableFromOpaqueRoots):
69         * API/JSMarkingConstraintPrivate.cpp:
70         (JSC::isMarked):
71         * API/glib/JSAPIWrapperObjectGLib.cpp:
72         (JSAPIWrapperObjectHandleOwner::isReachableFromOpaqueRoots):
73         * builtins/BuiltinExecutables.cpp:
74         (JSC::BuiltinExecutables::finalizeUnconditionally):
75         * bytecode/AccessCase.cpp:
76         (JSC::AccessCase::visitWeak const):
77         (JSC::AccessCase::propagateTransitions const):
78         * bytecode/CallLinkInfo.cpp:
79         (JSC::CallLinkInfo::visitWeak):
80         * bytecode/CallLinkStatus.cpp:
81         (JSC::CallLinkStatus::finalize):
82         * bytecode/CallLinkStatus.h:
83         * bytecode/CallVariant.cpp:
84         (JSC::CallVariant::finalize):
85         * bytecode/CallVariant.h:
86         * bytecode/CodeBlock.cpp:
87         (JSC::CodeBlock::shouldJettisonDueToWeakReference):
88         (JSC::CodeBlock::shouldJettisonDueToOldAge):
89         (JSC::shouldMarkTransition):
90         (JSC::CodeBlock::propagateTransitions):
91         (JSC::CodeBlock::determineLiveness):
92         (JSC::CodeBlock::finalizeLLIntInlineCaches):
93         (JSC::CodeBlock::finalizeUnconditionally):
94         (JSC::CodeBlock::jettison):
95         * bytecode/CodeBlock.h:
96         * bytecode/ExecutableToCodeBlockEdge.cpp:
97         (JSC::ExecutableToCodeBlockEdge::visitChildren):
98         (JSC::ExecutableToCodeBlockEdge::finalizeUnconditionally):
99         (JSC::ExecutableToCodeBlockEdge::runConstraint):
100         * bytecode/GetByIdStatus.cpp:
101         (JSC::GetByIdStatus::finalize):
102         * bytecode/GetByIdStatus.h:
103         * bytecode/GetByIdVariant.cpp:
104         (JSC::GetByIdVariant::finalize):
105         * bytecode/GetByIdVariant.h:
106         * bytecode/InByIdStatus.cpp:
107         (JSC::InByIdStatus::finalize):
108         * bytecode/InByIdStatus.h:
109         * bytecode/InByIdVariant.cpp:
110         (JSC::InByIdVariant::finalize):
111         * bytecode/InByIdVariant.h:
112         * bytecode/ObjectPropertyCondition.cpp:
113         (JSC::ObjectPropertyCondition::isStillLive const):
114         * bytecode/ObjectPropertyCondition.h:
115         * bytecode/ObjectPropertyConditionSet.cpp:
116         (JSC::ObjectPropertyConditionSet::areStillLive const):
117         * bytecode/ObjectPropertyConditionSet.h:
118         * bytecode/PolymorphicAccess.cpp:
119         (JSC::PolymorphicAccess::visitWeak const):
120         * bytecode/PropertyCondition.cpp:
121         (JSC::PropertyCondition::isStillLive const):
122         * bytecode/PropertyCondition.h:
123         * bytecode/PutByIdStatus.cpp:
124         (JSC::PutByIdStatus::finalize):
125         * bytecode/PutByIdStatus.h:
126         * bytecode/PutByIdVariant.cpp:
127         (JSC::PutByIdVariant::finalize):
128         * bytecode/PutByIdVariant.h:
129         * bytecode/RecordedStatuses.cpp:
130         (JSC::RecordedStatuses::finalizeWithoutDeleting):
131         (JSC::RecordedStatuses::finalize):
132         * bytecode/RecordedStatuses.h:
133         * bytecode/StructureSet.cpp:
134         (JSC::StructureSet::isStillAlive const):
135         * bytecode/StructureSet.h:
136         * bytecode/StructureStubInfo.cpp:
137         (JSC::StructureStubInfo::visitWeakReferences):
138         * dfg/DFGPlan.cpp:
139         (JSC::DFG::Plan::finalizeInGC):
140         (JSC::DFG::Plan::isKnownToBeLiveDuringGC):
141         * heap/GCIncomingRefCounted.h:
142         * heap/GCIncomingRefCountedInlines.h:
143         (JSC::GCIncomingRefCounted<T>::filterIncomingReferences):
144         * heap/GCIncomingRefCountedSet.h:
145         * heap/GCIncomingRefCountedSetInlines.h:
146         (JSC::GCIncomingRefCountedSet<T>::lastChanceToFinalize):
147         (JSC::GCIncomingRefCountedSet<T>::sweep):
148         (JSC::GCIncomingRefCountedSet<T>::removeAll): Deleted.
149         (JSC::GCIncomingRefCountedSet<T>::removeDead): Deleted.
150         * heap/Heap.cpp:
151         (JSC::Heap::addToRememberedSet):
152         (JSC::Heap::runEndPhase):
153         (JSC::Heap::sweepArrayBuffers):
154         (JSC::Heap::addCoreConstraints):
155         * heap/Heap.h:
156         * heap/HeapInlines.h:
157         (JSC::Heap::isMarked):
158         * heap/HeapSnapshotBuilder.cpp:
159         (JSC::HeapSnapshotBuilder::appendNode):
160         * heap/SlotVisitor.cpp:
161         (JSC::SlotVisitor::appendToMarkStack):
162         (JSC::SlotVisitor::visitChildren):
163         * jit/PolymorphicCallStubRoutine.cpp:
164         (JSC::PolymorphicCallStubRoutine::visitWeak):
165         * runtime/ErrorInstance.cpp:
166         (JSC::ErrorInstance::finalizeUnconditionally):
167         * runtime/InferredValueInlines.h:
168         (JSC::InferredValue::finalizeUnconditionally):
169         * runtime/StackFrame.h:
170         (JSC::StackFrame::isMarked const):
171         * runtime/Structure.cpp:
172         (JSC::Structure::isCheapDuringGC):
173         (JSC::Structure::markIfCheap):
174         * runtime/Structure.h:
175         * runtime/TypeProfiler.cpp:
176         (JSC::TypeProfiler::invalidateTypeSetCache):
177         * runtime/TypeProfiler.h:
178         * runtime/TypeSet.cpp:
179         (JSC::TypeSet::invalidateCache):
180         * runtime/TypeSet.h:
181         * runtime/WeakMapImpl.cpp:
182         (JSC::WeakMapImpl<WeakMapBucket<WeakMapBucketDataKeyValue>>::visitOutputConstraints):
183         * runtime/WeakMapImplInlines.h:
184         (JSC::WeakMapImpl<WeakMapBucket>::finalizeUnconditionally):
185
186 2019-03-25  Keith Miller  <keith_miller@apple.com>
187
188         ASSERTION FAILED: m_op == CompareStrictEq in JSC::DFG::Node::convertToCompareEqPtr(JSC::DFG::FrozenValue *, JSC::DFG::Edge)
189         https://bugs.webkit.org/show_bug.cgi?id=196176
190
191         Reviewed by Saam Barati.
192
193         convertToCompareEqPtr should allow for either CompareStrictEq or
194         the SameValue DFG node. This fixes the old assertion that only
195         allowed CompareStrictEq.
196
197         * dfg/DFGNode.h:
198         (JSC::DFG::Node::convertToCompareEqPtr):
199
200 2019-03-25  Tadeu Zagallo  <tzagallo@apple.com>
201
202         WebAssembly: f32.max with NaN generates incorrect result
203         https://bugs.webkit.org/show_bug.cgi?id=175691
204         <rdar://problem/33952228>
205
206         Reviewed by Saam Barati.
207
208         Fix the B3 and Air compilation for f32.max. In order to handle the NaN
209         case, we need an extra GreaterThan comparison on top of the existing
210         Equal and LessThan ones.
211
212         * wasm/WasmAirIRGenerator.cpp:
213         (JSC::Wasm::AirIRGenerator::addOp<OpType::F32Max>):
214         * wasm/wasm.json:
215
216 2019-03-25  Yusuke Suzuki  <ysuzuki@apple.com>
217
218         Unreviewed, speculative fix for CLoop build on CPU(UNKNOWN)
219         https://bugs.webkit.org/show_bug.cgi?id=195982
220
221         * jit/ExecutableAllocator.h:
222         (JSC::ExecutableAllocator::initializeUnderlyingAllocator):
223
224 2019-03-25  Gyuyoung Kim  <gyuyoung.kim@webkit.org>
225
226         Remove NavigatorContentUtils in WebCore/Modules
227         https://bugs.webkit.org/show_bug.cgi?id=196070
228
229         Reviewed by Alex Christensen.
230
231         NavigatorContentUtils was to support the custom scheme spec [1].
232         However, in WebKit side, no port has supported the feature in
233         WebKit layer after EFL port was removed. So there has been the
234         only IDL implementation of the NavigatorContentUtils in WebCore.
235         So we don't need to keep the implementation in WebCore anymore.
236
237         [1] https://html.spec.whatwg.org/multipage/system-state.html#custom-handlers
238
239         * Configurations/FeatureDefines.xcconfig:
240
241 2019-03-23  Mark Lam  <mark.lam@apple.com>
242
243         Rolling out r243032 and r243071 because the fix is incorrect.
244         https://bugs.webkit.org/show_bug.cgi?id=195892
245         <rdar://problem/48981239>
246
247         Not reviewed.
248
249         The fix is incorrect: it relies on being able to determine liveness of an object
250         in an ObjectPropertyCondition based on the state of the object's MarkedBit.
251         However, there's no guarantee that GC has run and that the MarkedBit is already
252         set even if the object is live.  As a result, we may not re-install adaptive
253         watchpoints based on presumed dead objects which are actually live.
254
255         I'm rolling this out, and will implement a more comprehensive fix to handle
256         watchpoint liveness later.
257
258         * bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp:
259         (JSC::AdaptiveInferredPropertyValueWatchpointBase::fire):
260         * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
261         (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
262         * bytecode/ObjectPropertyCondition.cpp:
263         (JSC::ObjectPropertyCondition::dumpInContext const):
264         * bytecode/StructureStubClearingWatchpoint.cpp:
265         (JSC::StructureStubClearingWatchpoint::fireInternal):
266         * dfg/DFGAdaptiveStructureWatchpoint.cpp:
267         (JSC::DFG::AdaptiveStructureWatchpoint::fireInternal):
268         * runtime/StructureRareData.cpp:
269         (JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal):
270
271 2019-03-23  Keith Miller  <keith_miller@apple.com>
272
273         Refactor clz/ctz and fix getLSBSet.
274         https://bugs.webkit.org/show_bug.cgi?id=196162
275
276         Reviewed by Saam Barati.
277
278         Refactor references of clz32/64 and ctz32 to use clz and ctz,
279         respectively.
280
281         * dfg/DFGAbstractInterpreterInlines.h:
282         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
283         * dfg/DFGOperations.cpp:
284         * runtime/JSBigInt.cpp:
285         (JSC::JSBigInt::digitDiv):
286         (JSC::JSBigInt::absoluteDivWithBigIntDivisor):
287         (JSC::JSBigInt::calculateMaximumCharactersRequired):
288         (JSC::JSBigInt::toStringBasePowerOfTwo):
289         (JSC::JSBigInt::compareToDouble):
290         * runtime/MathObject.cpp:
291         (JSC::mathProtoFuncClz32):
292
293 2019-03-23  Yusuke Suzuki  <ysuzuki@apple.com>
294
295         [JSC] Shrink sizeof(RegExp)
296         https://bugs.webkit.org/show_bug.cgi?id=196133
297
298         Reviewed by Mark Lam.
299
300         Some applications have many RegExp cells. But RegExp cells are very large (144B).
301         This patch reduces the size from 144B to 48B by,
302
303         1. Allocate Yarr::YarrCodeBlock in non-GC heap. We can avoid this allocation if JIT is disabled.
304         2. m_captureGroupNames and m_namedGroupToParenIndex are moved to RareData. They are only used when RegExp has named capture groups.
305
306         * runtime/RegExp.cpp:
307         (JSC::RegExp::finishCreation):
308         (JSC::RegExp::estimatedSize):
309         (JSC::RegExp::compile):
310         (JSC::RegExp::matchConcurrently):
311         (JSC::RegExp::compileMatchOnly):
312         (JSC::RegExp::deleteCode):
313         (JSC::RegExp::printTraceData):
314         * runtime/RegExp.h:
315         * runtime/RegExpInlines.h:
316         (JSC::RegExp::hasCodeFor):
317         (JSC::RegExp::matchInline):
318         (JSC::RegExp::hasMatchOnlyCodeFor):
319
320 2019-03-22  Keith Rollin  <krollin@apple.com>
321
322         Enable ThinLTO support in Production builds
323         https://bugs.webkit.org/show_bug.cgi?id=190758
324         <rdar://problem/45413233>
325
326         Reviewed by Daniel Bates.
327
328         Tweak JavaScriptCore's Base.xcconfig to be more in-line with other
329         .xcconfig files with regards to LTO settings. However, don't actually
330         enable LTO for JavaScriptCore. LTO is not enabled for JavaScriptCore
331         due to <rdar://problem/24543547>.
332
333         * Configurations/Base.xcconfig:
334
335 2019-03-22  Mark Lam  <mark.lam@apple.com>
336
337         Placate exception check validation in genericTypedArrayViewProtoFuncLastIndexOf().
338         https://bugs.webkit.org/show_bug.cgi?id=196154
339         <rdar://problem/49145307>
340
341         Reviewed by Filip Pizlo.
342
343         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
344         (JSC::genericTypedArrayViewProtoFuncLastIndexOf):
345
346 2019-03-22  Mark Lam  <mark.lam@apple.com>
347
348         Placate exception check validation in constructJSWebAssemblyLinkError().
349         https://bugs.webkit.org/show_bug.cgi?id=196152
350         <rdar://problem/49145257>
351
352         Reviewed by Michael Saboff.
353
354         * wasm/js/WebAssemblyLinkErrorConstructor.cpp:
355         (JSC::constructJSWebAssemblyLinkError):
356
357 2019-03-22  Timothy Hatcher  <timothy@apple.com>
358
359         Change macosx() to macos() in WK_API... and JSC_API... macros.
360         https://bugs.webkit.org/show_bug.cgi?id=196106
361
362         Reviewed by Brian Burg.
363
364         * API/JSBasePrivate.h:
365         * API/JSContext.h:
366         * API/JSContextPrivate.h:
367         * API/JSContextRef.h:
368         * API/JSContextRefInternal.h:
369         * API/JSContextRefPrivate.h:
370         * API/JSManagedValue.h:
371         * API/JSObjectRef.h:
372         * API/JSObjectRefPrivate.h:
373         * API/JSRemoteInspector.h:
374         * API/JSScript.h:
375         * API/JSTypedArray.h:
376         * API/JSValue.h:
377         * API/JSValuePrivate.h:
378         * API/JSValueRef.h:
379         * API/JSVirtualMachinePrivate.h:
380
381 2019-03-22  Yusuke Suzuki  <ysuzuki@apple.com>
382
383         Unreviewed, build fix for Windows
384         https://bugs.webkit.org/show_bug.cgi?id=196122
385
386         * runtime/FunctionExecutable.cpp:
387
388 2019-03-21  Yusuke Suzuki  <ysuzuki@apple.com>
389
390         [JSC] Shrink sizeof(FunctionExecutable) by 16bytes
391         https://bugs.webkit.org/show_bug.cgi?id=196122
392
393         Reviewed by Saam Barati.
394
395         This patch reduces sizeof(FunctionExecutable) by 16 bytes.
396
397         1. ScriptExecutable::m_numParametersForCall and ScriptExecutable::m_numParametersForConstruct are not used in a meaningful way. Removed them.
398         2. ScriptExecutable::m_lastLine and ScriptExecutable::m_endColumn can be calculated from UnlinkedFunctionExecutable. So FunctionExecutable does not need to hold it.
399            This patch adds GlobalExecutable, which are non-function ScriptExecutables, and move m_lastLine and m_endColumn to this class.
400         3. FunctionExecutable still needs to have the feature overriding m_lastLine and m_endColumn. We move overridden data in FunctionExecutable::RareData.
401
402         * CMakeLists.txt:
403         * JavaScriptCore.xcodeproj/project.pbxproj:
404         * Sources.txt:
405         * bytecode/UnlinkedFunctionExecutable.cpp:
406         (JSC::UnlinkedFunctionExecutable::link):
407         * runtime/EvalExecutable.cpp:
408         (JSC::EvalExecutable::EvalExecutable):
409         * runtime/EvalExecutable.h:
410         * runtime/FunctionExecutable.cpp:
411         (JSC::FunctionExecutable::FunctionExecutable):
412         (JSC::FunctionExecutable::ensureRareDataSlow):
413         (JSC::FunctionExecutable::overrideInfo):
414         * runtime/FunctionExecutable.h:
415         * runtime/GlobalExecutable.cpp: Copied from Source/JavaScriptCore/tools/FunctionOverrides.h.
416         * runtime/GlobalExecutable.h: Copied from Source/JavaScriptCore/tools/FunctionOverrides.h.
417         (JSC::GlobalExecutable::lastLine const):
418         (JSC::GlobalExecutable::endColumn const):
419         (JSC::GlobalExecutable::recordParse):
420         (JSC::GlobalExecutable::GlobalExecutable):
421         * runtime/ModuleProgramExecutable.cpp:
422         (JSC::ModuleProgramExecutable::ModuleProgramExecutable):
423         * runtime/ModuleProgramExecutable.h:
424         * runtime/ProgramExecutable.cpp:
425         (JSC::ProgramExecutable::ProgramExecutable):
426         * runtime/ProgramExecutable.h:
427         * runtime/ScriptExecutable.cpp:
428         (JSC::ScriptExecutable::clearCode):
429         (JSC::ScriptExecutable::installCode):
430         (JSC::ScriptExecutable::hasClearableCode const):
431         (JSC::ScriptExecutable::newCodeBlockFor):
432         (JSC::ScriptExecutable::typeProfilingEndOffset const):
433         (JSC::ScriptExecutable::recordParse):
434         (JSC::ScriptExecutable::lastLine const):
435         (JSC::ScriptExecutable::endColumn const):
436         * runtime/ScriptExecutable.h:
437         (JSC::ScriptExecutable::hasJITCodeForCall const):
438         (JSC::ScriptExecutable::hasJITCodeForConstruct const):
439         (JSC::ScriptExecutable::recordParse):
440         (JSC::ScriptExecutable::lastLine const): Deleted.
441         (JSC::ScriptExecutable::endColumn const): Deleted.
442         * tools/FunctionOverrides.h:
443
444 2019-03-21  Yusuke Suzuki  <ysuzuki@apple.com>
445
446         [JSC] Shrink sizeof(RegExpObject)
447         https://bugs.webkit.org/show_bug.cgi?id=196130
448
449         Reviewed by Saam Barati.
450
451         sizeof(RegExpObject) is 48B due to one bool flag. We should compress this flag into lower bit of RegExp* field so that we can make RegExpObject 32B.
452         It saves memory footprint 1.3% in RAMification's regexp.
453
454         * dfg/DFGSpeculativeJIT.cpp:
455         (JSC::DFG::SpeculativeJIT::compileNewRegexp):
456         (JSC::DFG::SpeculativeJIT::compileSetRegExpObjectLastIndex):
457         * ftl/FTLAbstractHeapRepository.h:
458         * ftl/FTLLowerDFGToB3.cpp:
459         (JSC::FTL::DFG::LowerDFGToB3::compileNewRegexp):
460         (JSC::FTL::DFG::LowerDFGToB3::compileSetRegExpObjectLastIndex):
461         * runtime/RegExpObject.cpp:
462         (JSC::RegExpObject::RegExpObject):
463         (JSC::RegExpObject::visitChildren):
464         (JSC::RegExpObject::getOwnPropertySlot):
465         (JSC::RegExpObject::defineOwnProperty):
466         * runtime/RegExpObject.h:
467
468 2019-03-21  Tomas Popela  <tpopela@redhat.com>
469
470         [JSC] Fix build after r243232 on unsupported 64bit architectures
471         https://bugs.webkit.org/show_bug.cgi?id=196072
472
473         Reviewed by Keith Miller.
474
475         As Keith suggested we already expect 16 free bits at the top of any
476         pointer for JSValue even for the unsupported 64 bit arches.
477
478         * bytecode/CodeOrigin.h:
479
480 2019-03-21  Mark Lam  <mark.lam@apple.com>
481
482         Remove an invalid assertion in DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNullOrUndefined().
483         https://bugs.webkit.org/show_bug.cgi?id=196116
484         <rdar://problem/48976951>
485
486         Reviewed by Filip Pizlo.
487
488         The DFG backend should not make assumptions about what optimizations the front end
489         will or will not do.  The assertion asserts that the operand cannot be known to be
490         a cell.  However, it is not guaranteed that the front end will fold away this case.
491         Also, the DFG backend is perfectly capable of generating code to handle the case
492         where the operand is a cell.
493
494         The attached test case demonstrates a case where the operand can be a known cell.
495         The test needs to be run with the concurrent JIT and GC, and is racy.  It used to
496         trip up this assertion about once every 10 runs or so.
497
498         * dfg/DFGSpeculativeJIT64.cpp:
499         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNullOrUndefined):
500
501 2019-03-21  Tadeu Zagallo  <tzagallo@apple.com>
502
503         JSC::createError should clear exception thrown by errorDescriptionForValue
504         https://bugs.webkit.org/show_bug.cgi?id=196089
505
506         Reviewed by Mark Lam.
507
508         errorDescriptionForValue returns a nullString in case of failure, but it
509         might also throw an OOM exception when resolving a rope string. We need
510         to clear any potential exceptions thrown by errorDescriptionForValue
511         before returning the OOM from JSC::createError.
512
513         * runtime/ExceptionHelpers.cpp:
514         (JSC::createError):
515
516 2019-03-21  Robin Morisset  <rmorisset@apple.com>
517
518         B3::Opcode can fit in a single byte, shrinking B3Value by 8 bytes
519         https://bugs.webkit.org/show_bug.cgi?id=196014
520
521         Reviewed by Keith Miller.
522
523         B3::Opcode has less than one hundred cases, so it can easily fit in one byte (from two currently)
524         This shrinks B3::Kind from 4 bytes to 2 (by removing the byte of padding at the end).
525         This in turns eliminate padding from B3::Value, shrinking it by 8 bytes (out of 80).
526
527         * b3/B3Opcode.h:
528
529 2019-03-21  Michael Catanzaro  <mcatanzaro@igalia.com>
530
531         Unreviewed, more clang 3.8 build fixes
532         https://bugs.webkit.org/show_bug.cgi?id=195947
533         <rdar://problem/49069219>
534
535         In the spirit of making our code worse to please old compilers....
536
537         * bindings/ScriptValue.cpp:
538         (Inspector::jsToInspectorValue):
539         * bytecode/GetterSetterAccessCase.cpp:
540         (JSC::GetterSetterAccessCase::create):
541         (JSC::GetterSetterAccessCase::clone const):
542         * bytecode/InstanceOfAccessCase.cpp:
543         (JSC::InstanceOfAccessCase::clone const):
544         * bytecode/IntrinsicGetterAccessCase.cpp:
545         (JSC::IntrinsicGetterAccessCase::clone const):
546         * bytecode/ModuleNamespaceAccessCase.cpp:
547         (JSC::ModuleNamespaceAccessCase::clone const):
548         * bytecode/ProxyableAccessCase.cpp:
549         (JSC::ProxyableAccessCase::clone const):
550
551 2019-03-21  Yusuke Suzuki  <ysuzuki@apple.com>
552
553         [JSC] Do not create JIT related data under non-JIT mode
554         https://bugs.webkit.org/show_bug.cgi?id=195982
555
556         Reviewed by Mark Lam.
557
558         We avoid creations of JIT related data structures under non-JIT mode.
559         This patch removes the following allocations.
560
561         1. JITThunks
562         2. FTLThunks
563         3. FixedVMPoolExecutableAllocator
564         4. noJITValueProfileSingleton since it is no longer used
565         5. ARM disassembler should be initialized when it is used
566         6. Wasm related data structures are accidentally allocated if VM::canUseJIT() == false &&
567            Options::useWebAssembly() == true. Add Wasm::isSupported() function to check the both conditions.
568
569         * CMakeLists.txt:
570         * JavaScriptCore.xcodeproj/project.pbxproj:
571         * heap/Heap.cpp:
572         (JSC::Heap::runEndPhase):
573         * jit/ExecutableAllocator.cpp:
574         (JSC::FixedVMPoolExecutableAllocator::~FixedVMPoolExecutableAllocator):
575         (JSC::ExecutableAllocator::initializeUnderlyingAllocator):
576         (JSC::ExecutableAllocator::isValid const):
577         (JSC::ExecutableAllocator::underMemoryPressure):
578         (JSC::ExecutableAllocator::memoryPressureMultiplier):
579         (JSC::ExecutableAllocator::allocate):
580         (JSC::ExecutableAllocator::isValidExecutableMemory):
581         (JSC::ExecutableAllocator::getLock const):
582         (JSC::ExecutableAllocator::committedByteCount):
583         (JSC::ExecutableAllocator::dumpProfile):
584         (JSC::startOfFixedExecutableMemoryPoolImpl):
585         (JSC::endOfFixedExecutableMemoryPoolImpl):
586         (JSC::ExecutableAllocator::initialize):
587         (JSC::ExecutableAllocator::initializeAllocator): Deleted.
588         (JSC::ExecutableAllocator::ExecutableAllocator): Deleted.
589         (JSC::ExecutableAllocator::~ExecutableAllocator): Deleted.
590         * jit/ExecutableAllocator.h:
591         (JSC::ExecutableAllocatorBase::isValid const):
592         (JSC::ExecutableAllocatorBase::underMemoryPressure):
593         (JSC::ExecutableAllocatorBase::memoryPressureMultiplier):
594         (JSC::ExecutableAllocatorBase::dumpProfile):
595         (JSC::ExecutableAllocatorBase::allocate):
596         (JSC::ExecutableAllocatorBase::setJITEnabled):
597         (JSC::ExecutableAllocatorBase::isValidExecutableMemory):
598         (JSC::ExecutableAllocatorBase::committedByteCount):
599         (JSC::ExecutableAllocatorBase::getLock const):
600         (JSC::ExecutableAllocator::isValid const): Deleted.
601         (JSC::ExecutableAllocator::underMemoryPressure): Deleted.
602         (JSC::ExecutableAllocator::memoryPressureMultiplier): Deleted.
603         (JSC::ExecutableAllocator::allocate): Deleted.
604         (JSC::ExecutableAllocator::setJITEnabled): Deleted.
605         (JSC::ExecutableAllocator::isValidExecutableMemory): Deleted.
606         (JSC::ExecutableAllocator::committedByteCount): Deleted.
607         (JSC::ExecutableAllocator::getLock const): Deleted.
608         * jsc.cpp:
609         (functionWebAssemblyMemoryMode):
610         * runtime/InitializeThreading.cpp:
611         (JSC::initializeThreading):
612         * runtime/JSGlobalObject.cpp:
613         (JSC::JSGlobalObject::init):
614         * runtime/JSLock.cpp:
615         (JSC::JSLock::didAcquireLock):
616         * runtime/Options.cpp:
617         (JSC::recomputeDependentOptions):
618         * runtime/VM.cpp:
619         (JSC::enableAssembler):
620         (JSC::VM::canUseAssembler):
621         (JSC::VM::VM):
622         * runtime/VM.h:
623         * wasm/WasmCapabilities.h: Added.
624         (JSC::Wasm::isSupported):
625         * wasm/WasmFaultSignalHandler.cpp:
626         (JSC::Wasm::enableFastMemory):
627
628 2019-03-21  Yusuke Suzuki  <ysuzuki@apple.com>
629
630         [JSC] Fix JSC build with newer ICU
631         https://bugs.webkit.org/show_bug.cgi?id=196098
632
633         Reviewed by Keith Miller.
634
635         IntlDateTimeFormat and IntlNumberFormat have switch statement over ICU's enums. However it lacks "default" clause so that
636         the compile error occurs when a new enum value is added in ICU side. We should have "default" clause which just fallbacks
637         "unknown"_s case. The behavior is not changed since we already have `return "unknown"_s;` statement anyway after the
638         switch statement. This patch just suppresses a compile error.
639
640         * runtime/IntlDateTimeFormat.cpp:
641         (JSC::IntlDateTimeFormat::partTypeString):
642         * runtime/IntlNumberFormat.cpp:
643         (JSC::IntlNumberFormat::partTypeString):
644
645 2019-03-21  Tadeu Zagallo  <tzagallo@apple.com>
646
647         JSObject::putDirectIndexSlowOrBeyondVectorLength should check if indexIsSufficientlyBeyondLengthForSparseMap
648         https://bugs.webkit.org/show_bug.cgi?id=196078
649         <rdar://problem/35925380>
650
651         Reviewed by Mark Lam.
652
653         Unlike the other variations of putByIndex, it only checked if the index
654         was larger than MIN_SPARSE_ARRAY_INDEX when the indexingType was
655         ALL_BLANK_INDEXING_TYPES. This resulted in a huge butterfly being
656         allocated for object literals (e.g. `{[9e4]: ...}`) and objects parsed
657         from JSON.
658
659         * runtime/JSObject.cpp:
660         (JSC::JSObject::putDirectIndexSlowOrBeyondVectorLength):
661
662 2019-03-21  Tadeu Zagallo  <tzagallo@apple.com>
663
664         CachedUnlinkedSourceCodeShape::m_provider should be a CachedRefPtr
665         https://bugs.webkit.org/show_bug.cgi?id=196079
666
667         Reviewed by Saam Barati.
668
669         It was mistakenly cached as CachedPtr, which was leaking the decoded SourceProvider.
670
671         * runtime/CachedTypes.cpp:
672         (JSC::CachedUnlinkedSourceCodeShape::encode):
673
674 2019-03-21  Mark Lam  <mark.lam@apple.com>
675
676         Placate exception check validation in operationArrayIndexOfString().
677         https://bugs.webkit.org/show_bug.cgi?id=196067
678         <rdar://problem/49056572>
679
680         Reviewed by Michael Saboff.
681
682         * dfg/DFGOperations.cpp:
683
684 2019-03-21  Xan Lopez  <xan@igalia.com>
685
686         [JSC][x86] Drop support for x87 floating point
687         https://bugs.webkit.org/show_bug.cgi?id=194853
688
689         Reviewed by Don Olmstead.
690
691         Require SSE2 throughout the codebase, and remove x87 support where
692         it was optionally available. SSE2 detection happens at compile
693         time through a static_assert.
694
695         * assembler/MacroAssemblerX86.h:
696         (JSC::MacroAssemblerX86::storeDouble):
697         (JSC::MacroAssemblerX86::moveDoubleToInts):
698         (JSC::MacroAssemblerX86::supportsFloatingPoint):
699         (JSC::MacroAssemblerX86::supportsFloatingPointTruncate):
700         (JSC::MacroAssemblerX86::supportsFloatingPointSqrt):
701         (JSC::MacroAssemblerX86::supportsFloatingPointAbs):
702         * assembler/MacroAssemblerX86Common.cpp:
703         * assembler/MacroAssemblerX86Common.h:
704         (JSC::MacroAssemblerX86Common::moveDouble):
705         (JSC::MacroAssemblerX86Common::loadDouble):
706         (JSC::MacroAssemblerX86Common::loadFloat):
707         (JSC::MacroAssemblerX86Common::storeDouble):
708         (JSC::MacroAssemblerX86Common::storeFloat):
709         (JSC::MacroAssemblerX86Common::convertDoubleToFloat):
710         (JSC::MacroAssemblerX86Common::convertFloatToDouble):
711         (JSC::MacroAssemblerX86Common::addDouble):
712         (JSC::MacroAssemblerX86Common::addFloat):
713         (JSC::MacroAssemblerX86Common::divDouble):
714         (JSC::MacroAssemblerX86Common::divFloat):
715         (JSC::MacroAssemblerX86Common::subDouble):
716         (JSC::MacroAssemblerX86Common::subFloat):
717         (JSC::MacroAssemblerX86Common::mulDouble):
718         (JSC::MacroAssemblerX86Common::mulFloat):
719         (JSC::MacroAssemblerX86Common::convertInt32ToDouble):
720         (JSC::MacroAssemblerX86Common::convertInt32ToFloat):
721         (JSC::MacroAssemblerX86Common::branchDouble):
722         (JSC::MacroAssemblerX86Common::branchFloat):
723         (JSC::MacroAssemblerX86Common::compareDouble):
724         (JSC::MacroAssemblerX86Common::compareFloat):
725         (JSC::MacroAssemblerX86Common::branchTruncateDoubleToInt32):
726         (JSC::MacroAssemblerX86Common::truncateDoubleToInt32):
727         (JSC::MacroAssemblerX86Common::truncateFloatToInt32):
728         (JSC::MacroAssemblerX86Common::branchConvertDoubleToInt32):
729         (JSC::MacroAssemblerX86Common::branchDoubleNonZero):
730         (JSC::MacroAssemblerX86Common::branchDoubleZeroOrNaN):
731         (JSC::MacroAssemblerX86Common::lshiftPacked):
732         (JSC::MacroAssemblerX86Common::rshiftPacked):
733         (JSC::MacroAssemblerX86Common::orPacked):
734         (JSC::MacroAssemblerX86Common::move32ToFloat):
735         (JSC::MacroAssemblerX86Common::moveFloatTo32):
736         (JSC::MacroAssemblerX86Common::moveConditionallyDouble):
737         (JSC::MacroAssemblerX86Common::moveConditionallyFloat):
738         * offlineasm/x86.rb:
739         * runtime/MathCommon.cpp:
740         (JSC::operationMathPow):
741
742 2019-03-21  Carlos Garcia Campos  <cgarcia@igalia.com>
743
744         [GLIB] User data not correctly passed to callback of functions and constructors with no parameters
745         https://bugs.webkit.org/show_bug.cgi?id=196073
746
747         Reviewed by Michael Catanzaro.
748
749         This is because GClosure always expects a first parameter as instance. In case of functions or constructors with
750         no parameters we insert a fake instance which is just a null pointer that is ignored by the callback. But
751         if the function/constructor has user data the callback will expect one parameter for the user data. In that case
752         we can simply swap instance/user data so that the fake instance will be the second argument and user data the
753         first one.
754
755         * API/glib/JSCClass.cpp:
756         (jscClassCreateConstructor): Use g_cclosure_new_swap() if parameters is empty and user data was provided.
757         * API/glib/JSCValue.cpp:
758         (jscValueFunctionCreate): Ditto.
759
760 2019-03-21  Pablo Saavedra  <psaavedra@igalia.com>
761
762         [JSC][32-bit] Build failure after r243232
763         https://bugs.webkit.org/show_bug.cgi?id=196068
764
765         Reviewed by Mark Lam.
766
767         * dfg/DFGOSRExit.cpp:
768         (JSC::DFG::reifyInlinedCallFrames):
769         * dfg/DFGOSRExitCompilerCommon.cpp:
770         (JSC::DFG::reifyInlinedCallFrames):
771
772 2019-03-21  Carlos Garcia Campos  <cgarcia@igalia.com>
773
774         [GLib] Returning G_TYPE_OBJECT from a method does not work
775         https://bugs.webkit.org/show_bug.cgi?id=195574
776
777         Reviewed by Michael Catanzaro.
778
779         Add more documentation to clarify the ownership of wrapped objects when created and when returned by functions.
780
781         * API/glib/JSCCallbackFunction.cpp:
782         (JSC::JSCCallbackFunction::construct): Also allow to return boxed types from a constructor.
783         * API/glib/JSCClass.cpp:
784         * API/glib/JSCValue.cpp:
785
786 2019-03-21  Mark Lam  <mark.lam@apple.com>
787
788         Cap length of an array with spread to MIN_ARRAY_STORAGE_CONSTRUCTION_LENGTH.
789         https://bugs.webkit.org/show_bug.cgi?id=196055
790         <rdar://problem/49067448>
791
792         Reviewed by Yusuke Suzuki.
793
794         We are doing this because:
795         1. We expect the array to be densely packed.
796         2. SpeculativeJIT::compileAllocateNewArrayWithSize() (and the FTL equivalent)
797            expects the array length to be less than MIN_ARRAY_STORAGE_CONSTRUCTION_LENGTH
798            if we don't want to use an ArrayStorage shape.
799         3. There's no reason why an array with spread needs to be that large anyway.
800            MIN_ARRAY_STORAGE_CONSTRUCTION_LENGTH is plenty.
801
802         In this patch, we also add a debug assert in compileAllocateNewArrayWithSize() and
803         emitAllocateButterfly() to check for overflows.
804
805         * assembler/AbortReason.h:
806         * dfg/DFGOperations.cpp:
807         * dfg/DFGSpeculativeJIT.cpp:
808         (JSC::DFG::SpeculativeJIT::compileCreateRest):
809         (JSC::DFG::SpeculativeJIT::compileNewArrayWithSpread):
810         (JSC::DFG::SpeculativeJIT::emitAllocateButterfly):
811         (JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize):
812         * ftl/FTLLowerDFGToB3.cpp:
813         (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSpread):
814         * runtime/ArrayConventions.h:
815         * runtime/CommonSlowPaths.cpp:
816         (JSC::SLOW_PATH_DECL):
817
818 2019-03-20  Yusuke Suzuki  <ysuzuki@apple.com>
819
820         [JSC] Use finalizer in JSGlobalLexicalEnvironment and JSGlobalObject
821         https://bugs.webkit.org/show_bug.cgi?id=195992
822
823         Reviewed by Keith Miller and Mark Lam.
824
825         JSGlobalLexicalEnvironment and JSGlobalObject have their own CompleteSubspace to call destructors while they are not inheriting JSDestructibleObject.
826         But it is too costly since (1) it requires CompleteSubspace in VM, (2) both objects allocate MarkedBlocks while # of them are really small.
827
828         Instead of using CompleteSubspace, we just set finalizers for them. Since these objects are rarely allocated, setting finalizers does not show
829         memory / performance problems (actually, previously we used finalizer for ArrayPrototype due to the same reason, and it does not show any problems).
830
831         And we also add following two changes to JSSegmentedVariableObject.
832
833         1. Remove one boolean used for debugging in Release build. It enlarges sizeof(JSSegmentedVariableObject) and allocates one more MarkedBlock.
834         2. Use cellLock() instead.
835
836         * CMakeLists.txt:
837         * JavaScriptCore.xcodeproj/project.pbxproj:
838         * Sources.txt:
839         * runtime/JSSegmentedVariableObject.cpp:
840         (JSC::JSSegmentedVariableObject::findVariableIndex):
841         (JSC::JSSegmentedVariableObject::addVariables):
842         (JSC::JSSegmentedVariableObject::visitChildren):
843         (JSC::JSSegmentedVariableObject::~JSSegmentedVariableObject):
844         (JSC::JSSegmentedVariableObject::finishCreation):
845         * runtime/JSSegmentedVariableObject.h:
846         (JSC::JSSegmentedVariableObject::subspaceFor): Deleted.
847         * runtime/JSSegmentedVariableObjectHeapCellType.cpp: Removed.
848         * runtime/JSSegmentedVariableObjectHeapCellType.h: Removed.
849         * runtime/StringIteratorPrototype.cpp:
850         * runtime/VM.cpp:
851         (JSC::VM::VM):
852         * runtime/VM.h:
853
854 2019-03-20  Saam Barati  <sbarati@apple.com>
855
856         DFG::AbstractValue::validateOSREntry is wrong when isHeapTop and the incoming value is Empty
857         https://bugs.webkit.org/show_bug.cgi?id=195721
858
859         Reviewed by Filip Pizlo.
860
861         There was a check in AbstractValue::validateOSREntry where it checked
862         if isHeapTop(), and if so, just returned true. However, this is wrong
863         if the value we're checking against is the empty value, since HeapTop
864         does not include the Empty value. Instead, this check should be
865         isBytecodeTop(), which does account for the empty value.
866         
867         This patch also does a couple of other things:
868         - For our OSR entry AbstractValues, we were using HeapTop to mark
869          a dead value. That is now changed to BytecodeTop. (The idea here
870          is just to have validateOSREntry return early.)
871         - It wasn't obvious to me how I could make this fail in JS code.
872          The symptom we'd end up seeing is something like a nullptr derefernece
873          from forgetting to do a TDZ check. Instead, I've added a unit test.
874          This unit test lives in a new test file: testdfg. testdfg is similar
875          to testb3/testair/testapi.
876
877         * JavaScriptCore.xcodeproj/project.pbxproj:
878         * bytecode/SpeculatedType.h:
879         * dfg/DFGAbstractValue.h:
880         (JSC::DFG::AbstractValue::isBytecodeTop const):
881         (JSC::DFG::AbstractValue::validateOSREntryValue const):
882         * dfg/testdfg.cpp: Added.
883         (hiddenTruthBecauseNoReturnIsStupid):
884         (usage):
885         (JSC::DFG::testEmptyValueDoesNotValidateWithHeapTop):
886         (JSC::DFG::run):
887         (run):
888         (main):
889         * shell/CMakeLists.txt:
890
891 2019-03-20  Saam Barati  <sbarati@apple.com>
892
893         typeOfDoubleSum is wrong for when NaN can be produced
894         https://bugs.webkit.org/show_bug.cgi?id=196030
895
896         Reviewed by Filip Pizlo.
897
898         We were using typeOfDoubleSum(SpeculatedType, SpeculatedType) for add/sub/mul.
899         It assumed that the only way the resulting type could be NaN is if one of
900         the inputs were NaN. However, this is wrong. NaN can be produced in at least
901         these cases:
902           Infinity - Infinity
903           Infinity + (-Infinity)
904           Infinity * 0
905
906         * bytecode/SpeculatedType.cpp:
907         (JSC::typeOfDoubleSumOrDifferenceOrProduct):
908         (JSC::typeOfDoubleSum):
909         (JSC::typeOfDoubleDifference):
910         (JSC::typeOfDoubleProduct):
911
912 2019-03-20  Simon Fraser  <simon.fraser@apple.com>
913
914         Rename ENABLE_ACCELERATED_OVERFLOW_SCROLLING macro to ENABLE_OVERFLOW_SCROLLING_TOUCH
915         https://bugs.webkit.org/show_bug.cgi?id=196049
916
917         Reviewed by Tim Horton.
918
919         This macro is about the -webkit-overflow-scrolling CSS property, not accelerated
920         overflow scrolling in general, so rename it.
921
922         * Configurations/FeatureDefines.xcconfig:
923
924 2019-03-20  Saam Barati  <sbarati@apple.com>
925
926         GetCallee does not report the correct type in AI
927         https://bugs.webkit.org/show_bug.cgi?id=195981
928
929         Reviewed by Yusuke Suzuki.
930
931         I found this as part of my work in:
932         https://bugs.webkit.org/show_bug.cgi?id=195924
933         
934         I'm not sure how to write a test for it.
935         
936         GetCallee was always reporting that the result is SpecFunction. However,
937         for eval, it may result in just a JSCallee object, which is not a JSFunction.
938
939         * dfg/DFGAbstractInterpreterInlines.h:
940         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
941
942 2019-03-20  Mark Lam  <mark.lam@apple.com>
943
944         Open source arm64e code.
945         https://bugs.webkit.org/show_bug.cgi?id=196012
946         <rdar://problem/49066237>
947
948         Reviewed by Keith Miller.
949
950         * JavaScriptCore.xcodeproj/project.pbxproj:
951         * Sources.txt:
952         * assembler/ARM64EAssembler.h: Added.
953         (JSC::ARM64EAssembler::encodeGroup1):
954         (JSC::ARM64EAssembler::encodeGroup2):
955         (JSC::ARM64EAssembler::encodeGroup4):
956         (JSC::ARM64EAssembler::pacia1716):
957         (JSC::ARM64EAssembler::pacib1716):
958         (JSC::ARM64EAssembler::autia1716):
959         (JSC::ARM64EAssembler::autib1716):
960         (JSC::ARM64EAssembler::paciaz):
961         (JSC::ARM64EAssembler::paciasp):
962         (JSC::ARM64EAssembler::pacibz):
963         (JSC::ARM64EAssembler::pacibsp):
964         (JSC::ARM64EAssembler::autiaz):
965         (JSC::ARM64EAssembler::autiasp):
966         (JSC::ARM64EAssembler::autibz):
967         (JSC::ARM64EAssembler::autibsp):
968         (JSC::ARM64EAssembler::xpaclri):
969         (JSC::ARM64EAssembler::pacia):
970         (JSC::ARM64EAssembler::pacib):
971         (JSC::ARM64EAssembler::pacda):
972         (JSC::ARM64EAssembler::pacdb):
973         (JSC::ARM64EAssembler::autia):
974         (JSC::ARM64EAssembler::autib):
975         (JSC::ARM64EAssembler::autda):
976         (JSC::ARM64EAssembler::autdb):
977         (JSC::ARM64EAssembler::paciza):
978         (JSC::ARM64EAssembler::pacizb):
979         (JSC::ARM64EAssembler::pacdza):
980         (JSC::ARM64EAssembler::pacdzb):
981         (JSC::ARM64EAssembler::autiza):
982         (JSC::ARM64EAssembler::autizb):
983         (JSC::ARM64EAssembler::autdza):
984         (JSC::ARM64EAssembler::autdzb):
985         (JSC::ARM64EAssembler::xpaci):
986         (JSC::ARM64EAssembler::xpacd):
987         (JSC::ARM64EAssembler::pacga):
988         (JSC::ARM64EAssembler::braa):
989         (JSC::ARM64EAssembler::brab):
990         (JSC::ARM64EAssembler::blraa):
991         (JSC::ARM64EAssembler::blrab):
992         (JSC::ARM64EAssembler::braaz):
993         (JSC::ARM64EAssembler::brabz):
994         (JSC::ARM64EAssembler::blraaz):
995         (JSC::ARM64EAssembler::blrabz):
996         (JSC::ARM64EAssembler::retaa):
997         (JSC::ARM64EAssembler::retab):
998         (JSC::ARM64EAssembler::eretaa):
999         (JSC::ARM64EAssembler::eretab):
1000         (JSC::ARM64EAssembler::linkPointer):
1001         (JSC::ARM64EAssembler::repatchPointer):
1002         (JSC::ARM64EAssembler::setPointer):
1003         (JSC::ARM64EAssembler::readPointer):
1004         (JSC::ARM64EAssembler::readCallTarget):
1005         (JSC::ARM64EAssembler::ret):
1006         * assembler/MacroAssembler.cpp:
1007         * assembler/MacroAssembler.h:
1008         * assembler/MacroAssemblerARM64.cpp:
1009         * assembler/MacroAssemblerARM64E.h: Added.
1010         (JSC::MacroAssemblerARM64E::tagReturnAddress):
1011         (JSC::MacroAssemblerARM64E::untagReturnAddress):
1012         (JSC::MacroAssemblerARM64E::tagPtr):
1013         (JSC::MacroAssemblerARM64E::untagPtr):
1014         (JSC::MacroAssemblerARM64E::removePtrTag):
1015         (JSC::MacroAssemblerARM64E::callTrustedPtr):
1016         (JSC::MacroAssemblerARM64E::call):
1017         (JSC::MacroAssemblerARM64E::callRegister):
1018         (JSC::MacroAssemblerARM64E::jump):
1019         * dfg/DFGOSRExit.cpp:
1020         (JSC::DFG::reifyInlinedCallFrames):
1021         * dfg/DFGOSRExitCompilerCommon.cpp:
1022         (JSC::DFG::reifyInlinedCallFrames):
1023         * ftl/FTLThunks.cpp:
1024         (JSC::FTL::genericGenerationThunkGenerator):
1025         * jit/CCallHelpers.h:
1026         (JSC::CCallHelpers::prepareForTailCallSlow):
1027         * jit/CallFrameShuffler.cpp:
1028         (JSC::CallFrameShuffler::prepareForTailCall):
1029         * jit/ExecutableAllocator.cpp:
1030         (JSC::ExecutableAllocator::allocate):
1031         * jit/ThunkGenerators.cpp:
1032         (JSC::arityFixupGenerator):
1033         * llint/LLIntOfflineAsmConfig.h:
1034         * llint/LowLevelInterpreter.asm:
1035         * llint/LowLevelInterpreter64.asm:
1036         * runtime/ClassInfo.h:
1037         * runtime/InitializeThreading.cpp:
1038         (JSC::initializeThreading):
1039         * runtime/JSCPtrTag.cpp: Added.
1040         (JSC::tagForPtr):
1041         (JSC::ptrTagName):
1042         (JSC::initializePtrTagLookup):
1043         * runtime/JSCPtrTag.h:
1044         (JSC::initializePtrTagLookup):
1045         * runtime/Options.cpp:
1046         (JSC::recomputeDependentOptions):
1047
1048 2019-03-20  Tadeu Zagallo  <tzagallo@apple.com>
1049
1050         JSC::createError needs to check for OOM in errorDescriptionForValue
1051         https://bugs.webkit.org/show_bug.cgi?id=196032
1052         <rdar://problem/46842740>
1053
1054         Reviewed by Mark Lam.
1055
1056         We were missing exceptions checks at two levels:
1057         - In errorDescriptionForValue, when the value is a string, we should
1058           check that JSString::value returns a valid string, since we might run
1059           out of memory if it is a rope and we need to resolve it.
1060         - In createError, we should check for the result of errorDescriptionForValue
1061           before concatenating it with the message provided by the caller.
1062
1063         * runtime/ExceptionHelpers.cpp:
1064         (JSC::errorDescriptionForValue):
1065         (JSC::createError):
1066         * runtime/ExceptionHelpers.h:
1067
1068 2019-03-20  Devin Rousso  <drousso@apple.com>
1069
1070         Web Inspector: DOM: include window as part of any event listener chain
1071         https://bugs.webkit.org/show_bug.cgi?id=195730
1072         <rdar://problem/48916872>
1073
1074         Reviewed by Timothy Hatcher.
1075
1076         * inspector/protocol/DOM.json:
1077         Modify `DOM.getEventListenersForNode` to not save the handler object, as that was never
1078         used by the frontend. Add an `onWindow` optional property to `DOM.EventListener` that is set
1079         when the event listener was retrieved from the `window` object.
1080
1081 2019-03-20  Devin Rousso  <drousso@apple.com>
1082
1083         Web Inspector: Runtime: lazily create the agent
1084         https://bugs.webkit.org/show_bug.cgi?id=195972
1085         <rdar://problem/49039655>
1086
1087         Reviewed by Timothy Hatcher.
1088
1089         * inspector/JSGlobalObjectInspectorController.cpp:
1090         (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
1091         (Inspector::JSGlobalObjectInspectorController::createLazyAgents):
1092
1093         * inspector/agents/InspectorRuntimeAgent.h:
1094         (Inspector::InspectorRuntimeAgent::enabled): Deleted.
1095         * inspector/agents/InspectorRuntimeAgent.cpp:
1096         (Inspector::InspectorRuntimeAgent::didCreateFrontendAndBackend): Added.
1097         (Inspector::InspectorRuntimeAgent::willDestroyFrontendAndBackend):
1098
1099         * inspector/agents/JSGlobalObjectRuntimeAgent.h:
1100         * inspector/agents/JSGlobalObjectRuntimeAgent.cpp:
1101         (Inspector::JSGlobalObjectRuntimeAgent::didCreateFrontendAndBackend): Deleted.
1102
1103 2019-03-20  Michael Saboff  <msaboff@apple.com>
1104
1105         JSC test crash: stress/dont-strength-reduce-regexp-with-compile-error.js.default
1106         https://bugs.webkit.org/show_bug.cgi?id=195906
1107
1108         Reviewed by Mark Lam.
1109
1110         The problem here as that we may successfully parsed a RegExp without running out of stack,
1111         but later run out of stack when trying to JIT compile the same expression.
1112
1113         Added a check for available stack space when we call into one of the parenthesis compilation
1114         functions that recurse.  When we don't have enough stack space to recurse, we fail the JIT
1115         compilation and let the interpreter handle the expression.
1116
1117         From code inspection of the YARR interpreter it has the same issue, but I couldn't cause a failure.
1118         Filed a new bug and added a FIXME comment for the Interpreter to have similar checks.
1119         Given that we can reproduce a failure, this is sufficient for now.
1120
1121         This change is covered by the previously added failing test,
1122         JSTests/stress/dont-strength-reduce-regexp-with-compile-error.js.
1123
1124         * yarr/YarrInterpreter.cpp:
1125         (JSC::Yarr::Interpreter::interpret):
1126         * yarr/YarrJIT.cpp:
1127         (JSC::Yarr::YarrGenerator::opCompileParenthesesSubpattern):
1128         (JSC::Yarr::YarrGenerator::opCompileParentheticalAssertion):
1129         (JSC::Yarr::YarrGenerator::opCompileBody):
1130         (JSC::Yarr::dumpCompileFailure):
1131         * yarr/YarrJIT.h:
1132
1133 2019-03-20  Robin Morisset  <rmorisset@apple.com>
1134
1135         DFGNodeAllocator.h is dead code
1136         https://bugs.webkit.org/show_bug.cgi?id=196019
1137
1138         Reviewed by Yusuke Suzuki.
1139
1140         As explained by Yusuke on IRC, the comment on DFG::Node saying that it cannot have a destructor is obsolete since https://trac.webkit.org/changeset/216815/webkit.
1141         This patch removes both the comment and DFGNodeAllocator.h that that patch forgot to remove.
1142
1143         * dfg/DFGNode.h:
1144         (JSC::DFG::Node::dumpChildren):
1145         * dfg/DFGNodeAllocator.h: Removed.
1146
1147 2019-03-20  Robin Morisset  <rmorisset@apple.com>
1148
1149         Compress CodeOrigin into a single word in the common case
1150         https://bugs.webkit.org/show_bug.cgi?id=195928
1151
1152         Reviewed by Saam Barati.
1153
1154         The trick is that pointers only take 48 bits on x86_64 in practice (and we can even use the bottom three bits of that thanks to alignment), and even less on ARM64.
1155         So we can shove the bytecode index in the top bits almost all the time.
1156         If the bytecodeIndex is too ginormous (1<<16 in practice on x86_64), we just set one bit at the bottom and store a pointer to some out-of-line storage instead.
1157         Finally we represent an invalid bytecodeIndex (which used to be represented by UINT_MAX) by setting the second least signifcant bit.
1158
1159         The patch looks very long, but most of it is just replacing direct accesses to inlineCallFrame and bytecodeIndex by the relevant getters.
1160
1161         End result: CodeOrigin in the common case moves from 16 bytes (8 for InlineCallFrame*, 4 for unsigned bytecodeIndex, 4 of padding) to 8.
1162         As a reference, during running JetStream2 we allocate more than 35M CodeOrigins. While they won't all be alive at the same time, it is still quite a lot of objects, so I am hoping for some small
1163         improvement to RAMification from this work.
1164
1165         The one slightly tricky part is that we must implement copy and move assignment operators and constructors to make sure that any out-of-line storage belongs to a single CodeOrigin and is destroyed exactly once.
1166
1167         * bytecode/ByValInfo.h:
1168         * bytecode/CallLinkStatus.cpp:
1169         (JSC::CallLinkStatus::computeFor):
1170         * bytecode/CodeBlock.cpp:
1171         (JSC::CodeBlock::globalObjectFor):
1172         (JSC::CodeBlock::updateOSRExitCounterAndCheckIfNeedToReoptimize):
1173         (JSC::CodeBlock::bytecodeOffsetFromCallSiteIndex):
1174         * bytecode/CodeOrigin.cpp:
1175         (JSC::CodeOrigin::inlineDepth const):
1176         (JSC::CodeOrigin::isApproximatelyEqualTo const):
1177         (JSC::CodeOrigin::approximateHash const):
1178         (JSC::CodeOrigin::inlineStack const):
1179         (JSC::CodeOrigin::codeOriginOwner const):
1180         (JSC::CodeOrigin::stackOffset const):
1181         (JSC::CodeOrigin::dump const):
1182         (JSC::CodeOrigin::inlineDepthForCallFrame): Deleted.
1183         * bytecode/CodeOrigin.h:
1184         (JSC::OutOfLineCodeOrigin::OutOfLineCodeOrigin):
1185         (JSC::CodeOrigin::CodeOrigin):
1186         (JSC::CodeOrigin::~CodeOrigin):
1187         (JSC::CodeOrigin::isSet const):
1188         (JSC::CodeOrigin::isHashTableDeletedValue const):
1189         (JSC::CodeOrigin::bytecodeIndex const):
1190         (JSC::CodeOrigin::inlineCallFrame const):
1191         (JSC::CodeOrigin::buildCompositeValue):
1192         (JSC::CodeOrigin::hash const):
1193         (JSC::CodeOrigin::operator== const):
1194         (JSC::CodeOrigin::exitingInlineKind const): Deleted.
1195         * bytecode/DeferredSourceDump.h:
1196         * bytecode/GetByIdStatus.cpp:
1197         (JSC::GetByIdStatus::computeForStubInfo):
1198         (JSC::GetByIdStatus::computeFor):
1199         * bytecode/ICStatusMap.cpp:
1200         (JSC::ICStatusContext::isInlined const):
1201         * bytecode/InByIdStatus.cpp:
1202         (JSC::InByIdStatus::computeFor):
1203         (JSC::InByIdStatus::computeForStubInfo):
1204         * bytecode/InlineCallFrame.cpp:
1205         (JSC::InlineCallFrame::dumpInContext const):
1206         * bytecode/InlineCallFrame.h:
1207         (JSC::InlineCallFrame::computeCallerSkippingTailCalls):
1208         (JSC::InlineCallFrame::getCallerInlineFrameSkippingTailCalls):
1209         (JSC::baselineCodeBlockForOriginAndBaselineCodeBlock):
1210         (JSC::CodeOrigin::walkUpInlineStack):
1211         * bytecode/InstanceOfStatus.h:
1212         * bytecode/PutByIdStatus.cpp:
1213         (JSC::PutByIdStatus::computeForStubInfo):
1214         (JSC::PutByIdStatus::computeFor):
1215         * dfg/DFGAbstractInterpreterInlines.h:
1216         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1217         * dfg/DFGArgumentsEliminationPhase.cpp:
1218         * dfg/DFGArgumentsUtilities.cpp:
1219         (JSC::DFG::argumentsInvolveStackSlot):
1220         (JSC::DFG::emitCodeToGetArgumentsArrayLength):
1221         * dfg/DFGArrayMode.h:
1222         * dfg/DFGByteCodeParser.cpp:
1223         (JSC::DFG::ByteCodeParser::injectLazyOperandSpeculation):
1224         (JSC::DFG::ByteCodeParser::setLocal):
1225         (JSC::DFG::ByteCodeParser::setArgument):
1226         (JSC::DFG::ByteCodeParser::flushForTerminalImpl):
1227         (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
1228         (JSC::DFG::ByteCodeParser::parseBlock):
1229         (JSC::DFG::ByteCodeParser::parseCodeBlock):
1230         (JSC::DFG::ByteCodeParser::handlePutByVal):
1231         * dfg/DFGClobberize.h:
1232         (JSC::DFG::clobberize):
1233         * dfg/DFGConstantFoldingPhase.cpp:
1234         (JSC::DFG::ConstantFoldingPhase::foldConstants):
1235         * dfg/DFGFixupPhase.cpp:
1236         (JSC::DFG::FixupPhase::attemptToMakeGetArrayLength):
1237         * dfg/DFGForAllKills.h:
1238         (JSC::DFG::forAllKilledOperands):
1239         * dfg/DFGGraph.cpp:
1240         (JSC::DFG::Graph::dumpCodeOrigin):
1241         (JSC::DFG::Graph::dump):
1242         (JSC::DFG::Graph::isLiveInBytecode):
1243         (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
1244         (JSC::DFG::Graph::willCatchExceptionInMachineFrame):
1245         * dfg/DFGGraph.h:
1246         (JSC::DFG::Graph::executableFor):
1247         (JSC::DFG::Graph::isStrictModeFor):
1248         (JSC::DFG::Graph::hasExitSite):
1249         (JSC::DFG::Graph::forAllLocalsLiveInBytecode):
1250         * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
1251         (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlockForTryCatch):
1252         * dfg/DFGMinifiedNode.cpp:
1253         (JSC::DFG::MinifiedNode::fromNode):
1254         * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
1255         (JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
1256         * dfg/DFGOSRExit.cpp:
1257         (JSC::DFG::OSRExit::executeOSRExit):
1258         (JSC::DFG::reifyInlinedCallFrames):
1259         (JSC::DFG::adjustAndJumpToTarget):
1260         (JSC::DFG::printOSRExit):
1261         (JSC::DFG::OSRExit::compileExit):
1262         * dfg/DFGOSRExitBase.cpp:
1263         (JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSiteSlow):
1264         * dfg/DFGOSRExitCompilerCommon.cpp:
1265         (JSC::DFG::handleExitCounts):
1266         (JSC::DFG::reifyInlinedCallFrames):
1267         (JSC::DFG::adjustAndJumpToTarget):
1268         * dfg/DFGOSRExitPreparation.cpp:
1269         (JSC::DFG::prepareCodeOriginForOSRExit):
1270         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1271         * dfg/DFGOperations.cpp:
1272         * dfg/DFGPreciseLocalClobberize.h:
1273         (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
1274         * dfg/DFGSpeculativeJIT.cpp:
1275         (JSC::DFG::SpeculativeJIT::emitGetLength):
1276         (JSC::DFG::SpeculativeJIT::emitGetCallee):
1277         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
1278         (JSC::DFG::SpeculativeJIT::compileValueAdd):
1279         (JSC::DFG::SpeculativeJIT::compileValueSub):
1280         (JSC::DFG::SpeculativeJIT::compileValueNegate):
1281         (JSC::DFG::SpeculativeJIT::compileValueMul):
1282         (JSC::DFG::SpeculativeJIT::compileForwardVarargs):
1283         (JSC::DFG::SpeculativeJIT::compileCreateDirectArguments):
1284         * dfg/DFGSpeculativeJIT32_64.cpp:
1285         (JSC::DFG::SpeculativeJIT::emitCall):
1286         * dfg/DFGSpeculativeJIT64.cpp:
1287         (JSC::DFG::SpeculativeJIT::emitCall):
1288         (JSC::DFG::SpeculativeJIT::compile):
1289         * dfg/DFGTierUpCheckInjectionPhase.cpp:
1290         (JSC::DFG::TierUpCheckInjectionPhase::run):
1291         (JSC::DFG::TierUpCheckInjectionPhase::canOSREnterAtLoopHint):
1292         (JSC::DFG::TierUpCheckInjectionPhase::buildNaturalLoopToLoopHintMap):
1293         * dfg/DFGTypeCheckHoistingPhase.cpp:
1294         (JSC::DFG::TypeCheckHoistingPhase::run):
1295         * dfg/DFGVariableEventStream.cpp:
1296         (JSC::DFG::VariableEventStream::reconstruct const):
1297         * ftl/FTLLowerDFGToB3.cpp:
1298         (JSC::FTL::DFG::LowerDFGToB3::compileValueAdd):
1299         (JSC::FTL::DFG::LowerDFGToB3::compileValueSub):
1300         (JSC::FTL::DFG::LowerDFGToB3::compileValueMul):
1301         (JSC::FTL::DFG::LowerDFGToB3::compileArithAddOrSub):
1302         (JSC::FTL::DFG::LowerDFGToB3::compileValueNegate):
1303         (JSC::FTL::DFG::LowerDFGToB3::compileGetMyArgumentByVal):
1304         (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSpread):
1305         (JSC::FTL::DFG::LowerDFGToB3::compileSpread):
1306         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread):
1307         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
1308         (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargs):
1309         (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargsWithSpread):
1310         (JSC::FTL::DFG::LowerDFGToB3::getArgumentsLength):
1311         (JSC::FTL::DFG::LowerDFGToB3::getCurrentCallee):
1312         (JSC::FTL::DFG::LowerDFGToB3::getArgumentsStart):
1313         (JSC::FTL::DFG::LowerDFGToB3::codeOriginDescriptionOfCallSite const):
1314         * ftl/FTLOSRExitCompiler.cpp:
1315         (JSC::FTL::compileStub):
1316         * ftl/FTLOperations.cpp:
1317         (JSC::FTL::operationMaterializeObjectInOSR):
1318         * interpreter/CallFrame.cpp:
1319         (JSC::CallFrame::bytecodeOffset):
1320         * interpreter/StackVisitor.cpp:
1321         (JSC::StackVisitor::unwindToMachineCodeBlockFrame):
1322         (JSC::StackVisitor::readFrame):
1323         (JSC::StackVisitor::readNonInlinedFrame):
1324         (JSC::inlinedFrameOffset):
1325         (JSC::StackVisitor::readInlinedFrame):
1326         * interpreter/StackVisitor.h:
1327         * jit/AssemblyHelpers.cpp:
1328         (JSC::AssemblyHelpers::executableFor):
1329         * jit/AssemblyHelpers.h:
1330         (JSC::AssemblyHelpers::isStrictModeFor):
1331         (JSC::AssemblyHelpers::argumentsStart):
1332         (JSC::AssemblyHelpers::argumentCount):
1333         * jit/PCToCodeOriginMap.cpp:
1334         (JSC::PCToCodeOriginMap::PCToCodeOriginMap):
1335         (JSC::PCToCodeOriginMap::findPC const):
1336         * profiler/ProfilerOriginStack.cpp:
1337         (JSC::Profiler::OriginStack::OriginStack):
1338         * profiler/ProfilerOriginStack.h:
1339         * runtime/ErrorInstance.cpp:
1340         (JSC::appendSourceToError):
1341         * runtime/SamplingProfiler.cpp:
1342         (JSC::SamplingProfiler::processUnverifiedStackTraces):
1343
1344 2019-03-20  Devin Rousso  <drousso@apple.com>
1345
1346         Web Inspector: Search: allow DOM searches to be case sensitive
1347         https://bugs.webkit.org/show_bug.cgi?id=194673
1348         <rdar://problem/48087577>
1349
1350         Reviewed by Timothy Hatcher.
1351
1352         Since `DOM.performSearch` also searches by selector and XPath, some results may appear
1353         as unexpected. As an example, searching for "BoDy" will still return the <body> as a result,
1354         as although the literal node name ("BODY") didn't match, it did match via selector/XPath.
1355
1356         * inspector/protocol/DOM.json:
1357         Allow `DOM.performSearch` to be case sensitive.
1358
1359 2019-03-20  Saam Barati  <sbarati@apple.com>
1360
1361         AI rule for ValueBitNot/ValueBitXor/ValueBitAnd/ValueBitOr is wrong
1362         https://bugs.webkit.org/show_bug.cgi?id=195980
1363
1364         Reviewed by Yusuke Suzuki.
1365
1366         They were all saying they could be type: (SpecBoolInt32, SpecBigInt)
1367         However, they should have been type: (SpecInt32Only, SpecBigInt)
1368
1369         * dfg/DFGAbstractInterpreterInlines.h:
1370         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1371
1372 2019-03-20  Michael Catanzaro  <mcatanzaro@igalia.com>
1373
1374         Remove copyRef() calls added in r243163
1375         https://bugs.webkit.org/show_bug.cgi?id=195962
1376
1377         Reviewed by Chris Dumez.
1378
1379         As best I can tell, may be a GCC 9 bug. It shouldn't warn about this case because the return
1380         value is noncopyable and the WTFMove() is absolutely required. We can avoid the warning
1381         without refcount churn by introducing an intermediate variable.
1382
1383         * inspector/scripts/codegen/cpp_generator_templates.py:
1384
1385 2019-03-20  Carlos Garcia Campos  <cgarcia@igalia.com>
1386
1387         [GLIB] Optimize jsc_value_object_define_property_data|accessor
1388         https://bugs.webkit.org/show_bug.cgi?id=195679
1389
1390         Reviewed by Saam Barati.
1391
1392         Use direct C++ call instead of using the JSC GLib API to create the descriptor object and invoke Object.defineProperty().
1393
1394         * API/glib/JSCValue.cpp:
1395         (jsc_value_object_define_property_data):
1396         (jsc_value_object_define_property_accessor):
1397
1398 2019-03-19  Devin Rousso  <drousso@apple.com>
1399
1400         Web Inspector: Debugger: lazily create the agent
1401         https://bugs.webkit.org/show_bug.cgi?id=195973
1402         <rdar://problem/49039674>
1403
1404         Reviewed by Joseph Pecoraro.
1405
1406         * inspector/JSGlobalObjectInspectorController.cpp:
1407         (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
1408         (Inspector::JSGlobalObjectInspectorController::frontendInitialized):
1409         (Inspector::JSGlobalObjectInspectorController::createLazyAgents):
1410
1411         * inspector/JSGlobalObjectConsoleClient.h:
1412         (Inspector::JSGlobalObjectConsoleClient::setInspectorDebuggerAgent): Added.
1413         * inspector/JSGlobalObjectConsoleClient.cpp:
1414         (Inspector::JSGlobalObjectConsoleClient::JSGlobalObjectConsoleClient):
1415         (Inspector::JSGlobalObjectConsoleClient::startConsoleProfile):
1416         (Inspector::JSGlobalObjectConsoleClient::stopConsoleProfile):
1417
1418         * inspector/agents/InspectorDebuggerAgent.h:
1419         (Inspector::InspectorDebuggerAgent::addListener): Added.
1420         (Inspector::InspectorDebuggerAgent::removeListener): Added.
1421         (Inspector::InspectorDebuggerAgent::setListener): Deleted.
1422         * inspector/agents/InspectorDebuggerAgent.cpp:
1423         (Inspector::InspectorDebuggerAgent::InspectorDebuggerAgent):
1424         (Inspector::InspectorDebuggerAgent::enable):
1425         (Inspector::InspectorDebuggerAgent::disable):
1426         (Inspector::InspectorDebuggerAgent::getScriptSource):
1427         (Inspector::InspectorDebuggerAgent::schedulePauseOnNextStatement):
1428         (Inspector::InspectorDebuggerAgent::didPause):
1429         (Inspector::InspectorDebuggerAgent::breakProgram):
1430         (Inspector::InspectorDebuggerAgent::clearBreakDetails):
1431         Drive-by: reorder some member variables for better sizing.
1432         Drive-by: rename some member variables for clarity.
1433
1434 2019-03-19  Saam barati  <sbarati@apple.com>
1435
1436         Prune code after ForceOSRExit
1437         https://bugs.webkit.org/show_bug.cgi?id=195913
1438
1439         Reviewed by Keith Miller.
1440
1441         I removed our original implementation of this in r242989 because
1442         it was not sound. It broke backwards propagation because it removed
1443         uses of a node that backwards propagation relied on to be sound.
1444         Essentially, backwards propagation relies on being able to see uses
1445         that would exist in bytecode to be sound.
1446         
1447         The rollout in r242989 was a 1% Speedometer2 regression. This patch
1448         rolls back in the optimization in a sound way.
1449         
1450         This patch augments the code we had prior to r242989 to be sound. In
1451         addition to preserving liveness, we now also convert all uses after
1452         the ForceOSRExit to be Phantom. This may pessimize the optimizations
1453         we do in backwards propagation, but it will prevent that phase from
1454         making unsound optimizations.
1455
1456         * dfg/DFGByteCodeParser.cpp:
1457         (JSC::DFG::ByteCodeParser::addToGraph):
1458         (JSC::DFG::ByteCodeParser::parse):
1459
1460 2019-03-19  Michael Catanzaro  <mcatanzaro@igalia.com>
1461
1462         Build cleanly with GCC 9
1463         https://bugs.webkit.org/show_bug.cgi?id=195920
1464
1465         Reviewed by Chris Dumez.
1466
1467         WebKit triggers three new GCC 9 warnings:
1468
1469         """
1470         -Wdeprecated-copy, implied by -Wextra, warns about the C++11 deprecation of implicitly
1471         declared copy constructor and assignment operator if one of them is user-provided.
1472         """
1473
1474         Solution is to either add a copy constructor or copy assignment operator, if required, or
1475         else remove one if it is redundant.
1476
1477         """
1478         -Wredundant-move, implied by -Wextra, warns about redundant calls to std::move.
1479         -Wpessimizing-move, implied by -Wall, warns when a call to std::move prevents copy elision.
1480         """
1481
1482         These account for most of this patch. Solution is to just remove the bad WTFMove().
1483
1484         Additionally, -Wclass-memaccess has been enhanced to catch a few cases that GCC 8 didn't.
1485         These are solved by casting nontrivial types to void* before using memcpy. (Of course, it
1486         would be safer to not use memcpy on nontrivial types, but that's too complex for this
1487         patch. Searching for memcpy used with static_cast<void*> will reveal other cases to fix.)
1488
1489         * b3/B3ValueRep.h:
1490         * bindings/ScriptValue.cpp:
1491         (Inspector::jsToInspectorValue):
1492         * bytecode/GetterSetterAccessCase.cpp:
1493         (JSC::GetterSetterAccessCase::create):
1494         (JSC::GetterSetterAccessCase::clone const):
1495         * bytecode/InstanceOfAccessCase.cpp:
1496         (JSC::InstanceOfAccessCase::clone const):
1497         * bytecode/IntrinsicGetterAccessCase.cpp:
1498         (JSC::IntrinsicGetterAccessCase::clone const):
1499         * bytecode/ModuleNamespaceAccessCase.cpp:
1500         (JSC::ModuleNamespaceAccessCase::clone const):
1501         * bytecode/ProxyableAccessCase.cpp:
1502         (JSC::ProxyableAccessCase::clone const):
1503         * bytecode/StructureSet.h:
1504         * debugger/Breakpoint.h:
1505         * dfg/DFGRegisteredStructureSet.h:
1506         * inspector/agents/InspectorDebuggerAgent.cpp:
1507         (Inspector::buildDebuggerLocation):
1508         * inspector/scripts/codegen/cpp_generator_templates.py:
1509         * parser/UnlinkedSourceCode.h:
1510         * wasm/WasmAirIRGenerator.cpp:
1511         (JSC::Wasm::parseAndCompileAir):
1512         * wasm/WasmB3IRGenerator.cpp:
1513         (JSC::Wasm::parseAndCompile):
1514         * wasm/WasmNameSectionParser.cpp:
1515         (JSC::Wasm::NameSectionParser::parse):
1516         * wasm/WasmStreamingParser.cpp:
1517         (JSC::Wasm::StreamingParser::consume):
1518
1519 2019-03-19  Saam Barati  <sbarati@apple.com>
1520
1521         Style fix: remove C style cast in Instruction.h
1522         https://bugs.webkit.org/show_bug.cgi?id=195917
1523
1524         Reviewed by Filip Pizlo.
1525
1526         * bytecode/Instruction.h:
1527         (JSC::Instruction::wide const):
1528
1529 2019-03-19  Devin Rousso  <drousso@apple.com>
1530
1531         Web Inspector: Provide $event in the console when paused on an event listener
1532         https://bugs.webkit.org/show_bug.cgi?id=188672
1533
1534         Reviewed by Timothy Hatcher.
1535
1536         * inspector/InjectedScript.h:
1537         * inspector/InjectedScript.cpp:
1538         (Inspector::InjectedScript::setEventValue): Added.
1539         (Inspector::InjectedScript::clearEventValue): Added.
1540
1541         * inspector/InjectedScriptManager.h:
1542         * inspector/InjectedScriptManager.cpp:
1543         (Inspector::InjectedScriptManager::clearEventValue): Added.
1544
1545         * inspector/InjectedScriptSource.js:
1546         (WI.InjectedScript.prototype.setEventValue): Added.
1547         (WI.InjectedScript.prototype.clearEventValue): Added.
1548         (BasicCommandLineAPI):
1549
1550 2019-03-19  Devin Rousso  <drousso@apple.com>
1551
1552         Web Inspector: ScriptProfiler: lazily create the agent
1553         https://bugs.webkit.org/show_bug.cgi?id=195591
1554         <rdar://problem/48791756>
1555
1556         Reviewed by Joseph Pecoraro.
1557
1558         * inspector/JSGlobalObjectConsoleClient.h:
1559         (Inspector::JSGlobalObjectConsoleClient::setInspectorScriptProfilerAgent): Added.
1560         * inspector/JSGlobalObjectConsoleClient.cpp:
1561         (Inspector::JSGlobalObjectConsoleClient::JSGlobalObjectConsoleClient):
1562         (Inspector::JSGlobalObjectConsoleClient::startConsoleProfile):
1563         (Inspector::JSGlobalObjectConsoleClient::stopConsoleProfile):
1564
1565         * inspector/JSGlobalObjectInspectorController.cpp:
1566         (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
1567         (Inspector::JSGlobalObjectInspectorController::createLazyAgents):
1568
1569 2019-03-19  Devin Rousso  <drousso@apple.com>
1570
1571         Web Inspector: Heap: lazily create the agent
1572         https://bugs.webkit.org/show_bug.cgi?id=195590
1573         <rdar://problem/48791750>
1574
1575         Reviewed by Joseph Pecoraro.
1576
1577         * inspector/agents/InspectorHeapAgent.h:
1578         * inspector/agents/InspectorHeapAgent.cpp:
1579         (Inspector::InspectorHeapAgent::~InspectorHeapAgent): Deleted.
1580
1581         * inspector/agents/InspectorConsoleAgent.h:
1582         (Inspector::InspectorConsoleAgent::setInspectorHeapAgent): Added.
1583         * inspector/agents/InspectorConsoleAgent.cpp:
1584         (Inspector::InspectorConsoleAgent::InspectorConsoleAgent):
1585         (Inspector::InspectorConsoleAgent::takeHeapSnapshot):
1586         (Inspector::InspectorConsoleAgent::~InspectorConsoleAgent): Deleted.
1587
1588         * inspector/JSGlobalObjectInspectorController.cpp:
1589         (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
1590         (Inspector::JSGlobalObjectInspectorController::createLazyAgents):
1591
1592 2019-03-19  Caio Lima  <ticaiolima@gmail.com>
1593
1594         [JSC] LLIntEntryPoint creates same DirectJITCode for all functions
1595         https://bugs.webkit.org/show_bug.cgi?id=194648
1596
1597         Reviewed by Keith Miller.
1598
1599         1. Making LLIntThunks singleton. 
1600
1601         Motivation: Former implementation has one LLIntThunk per type per VM.
1602         However, the generated code for every kind of thunk is essentially the
1603         same and we end up wasting memory (right now jitAllocationGranule = 32 bytes)
1604         when we have 2 or more VM instantiated. Turn these thunks into
1605         singleton will avoid such wasting.
1606
1607         Tradeoff: This change comes with a price, because we will keep thunks
1608         allocated even when there is no VM instantiated. Considering WebCore use case,
1609         the situation of having no VM instantiated is uncommon, since once a
1610         VM is created through `commomVM()`, it will never be destroyed. Given
1611         that, this change does not impact the overall memory comsumption of
1612         WebCore/JSC. It also doesn't impact memory footprint, since thunks are
1613         generated lazily (see results below).
1614
1615         Since we are keeping a static `MacroAssemblerCodeRef<JITThunkPtrTag>`,
1616         we have the assurance that JITed code will never be deallocated,
1617         given it is being pointed by `RefPtr<ExecutableMemoryHandle> m_executableMemory`.
1618         To understand why we decided to make LLIntThunks singleton instead of
1619         removing them, please see the comment on `llint/LLIntThunks.cpp`.
1620
1621         2. Making all LLIntEntrypoints singleton
1622
1623         Motivation: With singleton LLIntThunks, we also can have singleton
1624         DirectJITCodes and NativeJITCodes for each LLIntEntrypoint type and
1625         avoid multiple allocations of objects with the same content.
1626
1627         Tradeoff: As explained before, once we allocate an entrypoint, it
1628         will be alive until the program exits. However, the gains we can
1629         achieve in some use cases justifies such allocations.
1630
1631         As DirectJITCode and NativeJITCode are ThreadSafeRefCounted and we are using
1632         `codeBlock->setJITCode(makeRef(*jitCode))`, their reference counter
1633         will never be less than 1.
1634
1635         3. Memory usage analysis
1636
1637         This change reduces memory usage on stress/generate-multiple-llint-entrypoints.js
1638         by 2% and is neutral on JetStream 2. Following results were generated
1639         running each benchmark 6 times and using 95% Student's t distribution
1640         confidence interval.
1641
1642         microbenchmarks/generate-multiple-llint-entrypoints.js (Changes uses less memory): 
1643             Mean of memory peak on ToT: 122576896 bytes (confidence interval: 67747.2316)
1644             Mean of memory peak on Changes: 119248213.33 bytes (confidence interval: 50251.2718)
1645
1646         JetStream2 (Neutral):
1647             Mean of memory peak on ToT: 5442742272 bytes (confidence interval: 134381565.9117)
1648             Mean of memory peak on Changes: 5384949760 bytes (confidence interval: 158413904.8352)
1649
1650         4. Performance Analysis
1651
1652         This change is performance neutral on JetStream 2 and Speedometer 2.
1653         See results below.:
1654
1655         JetStream 2 (Neutral):
1656             Mean of score on ToT: 139.58 (confidence interval: 2.44)
1657             Mean of score on Changes: 141.46 (confidence interval: 4.24)
1658
1659         Speedometer run #1
1660            ToT: 110 +- 2.9
1661            Changes: 110 +- 1.8
1662
1663         Speedometer run #2
1664            ToT: 110 +- 1.6
1665            Changes: 108 +- 2.3
1666
1667         Speedometer run #3
1668            ToT: 110 +- 3.0
1669            Changes: 110 +- 1.4
1670
1671         * jit/JSInterfaceJIT.h:
1672         (JSC::JSInterfaceJIT::JSInterfaceJIT):
1673         * llint/LLIntEntrypoint.cpp:
1674
1675         Here we are changing the usage or DirectJITCode by NativeJITCode on cases
1676         where there is no difference from address of calls with and without
1677         ArithCheck.
1678
1679         (JSC::LLInt::setFunctionEntrypoint):
1680         (JSC::LLInt::setEvalEntrypoint):
1681         (JSC::LLInt::setProgramEntrypoint):
1682         (JSC::LLInt::setModuleProgramEntrypoint):
1683         (JSC::LLInt::setEntrypoint):
1684         * llint/LLIntEntrypoint.h:
1685         * llint/LLIntThunks.cpp:
1686         (JSC::LLInt::generateThunkWithJumpTo):
1687         (JSC::LLInt::functionForCallEntryThunk):
1688         (JSC::LLInt::functionForConstructEntryThunk):
1689         (JSC::LLInt::functionForCallArityCheckThunk):
1690         (JSC::LLInt::functionForConstructArityCheckThunk):
1691         (JSC::LLInt::evalEntryThunk):
1692         (JSC::LLInt::programEntryThunk):
1693         (JSC::LLInt::moduleProgramEntryThunk):
1694         (JSC::LLInt::functionForCallEntryThunkGenerator): Deleted.
1695         (JSC::LLInt::functionForConstructEntryThunkGenerator): Deleted.
1696         (JSC::LLInt::functionForCallArityCheckThunkGenerator): Deleted.
1697         (JSC::LLInt::functionForConstructArityCheckThunkGenerator): Deleted.
1698         (JSC::LLInt::evalEntryThunkGenerator): Deleted.
1699         (JSC::LLInt::programEntryThunkGenerator): Deleted.
1700         (JSC::LLInt::moduleProgramEntryThunkGenerator): Deleted.
1701         * llint/LLIntThunks.h:
1702         * runtime/ScriptExecutable.cpp:
1703         (JSC::setupLLInt):
1704         (JSC::ScriptExecutable::prepareForExecutionImpl):
1705
1706 2019-03-18  Yusuke Suzuki  <ysuzuki@apple.com>
1707
1708         [JSC] Add missing exception checks revealed by newly added exception checks, follow-up after r243081
1709         https://bugs.webkit.org/show_bug.cgi?id=195927
1710
1711         Reviewed by Mark Lam.
1712
1713         r243081 adds more exception checks which are previously missing, and it reveals missing exception checks in the caller.
1714         This patch is a follow-up patch after r243081, adding missing exception checks more to fix debug test failures.
1715
1716         * runtime/RegExpConstructor.cpp:
1717         (JSC::setRegExpConstructorInput):
1718         (JSC::setRegExpConstructorMultiline):
1719         * runtime/RegExpGlobalData.cpp:
1720         (JSC::RegExpGlobalData::getBackref):
1721         (JSC::RegExpGlobalData::getLastParen):
1722
1723 2019-03-18  Yusuke Suzuki  <ysuzuki@apple.com>
1724
1725         [JSC] Generator should not create JSLexicalEnvironment if it is not necessary
1726         https://bugs.webkit.org/show_bug.cgi?id=195901
1727
1728         Reviewed by Saam Barati.
1729
1730         It is not rare that generators do not need to have any registers to be suspended and resumed.
1731         Since currently we always emit op_create_lexical_environment for generator code, we sometimes
1732         create empty JSLexicalEnvironment while it is not required. We can see that a lot of empty JSLexicalEnvironment
1733         are allocated in RAMification's Basic test.
1734
1735         This patch removes this unnecessary allocation. We introduce op_create_generator_frame_environment, which is
1736         a marker, similar to op_yield. And generatorification phase decides whether we should actually emit op_create_lexical_environment,
1737         based on the result of the analysis in generatorification. This can remove unnecessary JSLexicalEnvironment allocations.
1738
1739         We run RAMification in 6 times, use average of them.
1740         RAMification's Basic in JIT mode shows 1.4% improvement.
1741         ToT
1742             Current: 55076864.00, Peak: 55080960.00
1743         Patched
1744             Current: 54325930.67, Peak: 54329344.00
1745
1746         RAMification's Basic in non-JIT mode shows 5.0% improvement.
1747         ToT
1748             Current: 12485290.67, Peak: 12485290.67
1749         Patched
1750             Current: 11894101.33, Peak: 11894101.33
1751
1752         * bytecode/BytecodeGeneratorification.cpp:
1753         (JSC::BytecodeGeneratorification::BytecodeGeneratorification):
1754         (JSC::BytecodeGeneratorification::generatorFrameData const):
1755         (JSC::BytecodeGeneratorification::run):
1756         * bytecode/BytecodeList.rb:
1757         * bytecode/BytecodeUseDef.h:
1758         (JSC::computeUsesForBytecodeOffset):
1759         (JSC::computeDefsForBytecodeOffset):
1760         * bytecompiler/BytecodeGenerator.cpp:
1761         (JSC::BytecodeGenerator::BytecodeGenerator):
1762         * dfg/DFGCapabilities.cpp:
1763         (JSC::DFG::capabilityLevel):
1764         * llint/LowLevelInterpreter.asm:
1765
1766 2019-03-18  Robin Morisset  <rmorisset@apple.com>
1767
1768         Remove the inline capacity of Operands
1769         https://bugs.webkit.org/show_bug.cgi?id=195898
1770
1771         Reviewed by Yusuke Suzuki.
1772
1773         Operands currently has a vector with an inline capacity of 24.
1774         I tested on JetStream2, and only 4776 functions out of 12035 (that reach the DFG tier) have 24 or fewer elements in it.
1775         This is a major problem, because we have 5 Operands in every DFG::BasicBlock, resulting in 2688 bytes of inline capacity per basic block.
1776         Still on JetStream 2, functions have an average of 18 BB, but those functions whose operands overflow have an average of 27 BB (so we are wasting 72kB on average when compiling them), and the largest function has 1241 BB (!), for a total of 3.3MB being wasted while it is compiled.
1777         
1778         So I removed the inline capacity of the vector in Operands, and here are the results:
1779         Baseline Jetstream2:
1780         159.741
1781         159.746
1782         159.989
1783         Baseline RAMification on grouped and jit tests: (end/peak/score)
1784         89.288/89.763/89.526
1785         90.166/90.761/90.418
1786         89.560/90.014/89.787
1787         After optimization Jetstream2:
1788         159.342
1789         161.812
1790         162.037
1791         After optimization RAMification:
1792         89.147/89.644/89.395
1793         89.102.89.585/89.343
1794         88.953/89.536/89.2444
1795         
1796         So it looks like a roughly 1% improvement on RAMification (at least the tests where the JIT is enabled), and more surprisingly also a 1% progression on Jetstream2 (although I have more doubts about this one considering the variability in my numbers).
1797         I hope to land this, and get more accurate results from the bots.
1798
1799         * bytecode/Operands.h:
1800
1801 2019-03-18  Yusuke Suzuki  <ysuzuki@apple.com>
1802
1803         [JSC] Add --destroy-vm shell option and dumpHeapStatisticsAtVMDestruction option
1804         https://bugs.webkit.org/show_bug.cgi?id=195897
1805
1806         Reviewed by Keith Miller.
1807
1808         It is useful if we have an option logging the status of all the existing MarkedBlocks and their objects at VM destruction.
1809         I used this feature to find wasting memory, and successfully removed many wasted MarkedBlocks and JS cells like r243081.
1810         This patch adds,
1811
1812         1. --destroy-vm option to JSC shell to destroy main thread JSC::VM
1813         2. dumpHeapStatisticsAtVMDestruction to dump MarkedBlocks at VM destruction
1814
1815         While the current option name is "dumpHeapStatisticsAtVMDestruction", we just dump the status of MarkedBlocks and cells. But eventually,
1816         we would like to collect heap statistics and dump them to investigate Heap status more.
1817
1818         This patch also removes logHeapStatisticsAtExit option since it is no longer used in JSC.
1819
1820         * heap/Heap.cpp:
1821         (JSC::Heap::dumpHeapStatisticsAtVMDestruction):
1822         (JSC::Heap::lastChanceToFinalize):
1823         * heap/Heap.h:
1824         * jsc.cpp:
1825         (printUsageStatement):
1826         (CommandLine::parseArguments):
1827         (runJSC):
1828         * runtime/Options.h:
1829
1830 2019-03-18  Yusuke Suzuki  <ysuzuki@apple.com>
1831
1832         [JSC] jsSubstring should resolve rope before calling JSRopeString::create
1833         https://bugs.webkit.org/show_bug.cgi?id=195840
1834
1835         Reviewed by Geoffrey Garen.
1836
1837         jsSubstring always ends up resolving rope of the base string because substring JSRopeString only accepts non-rope JSString
1838         as its base. Instead of resolving ropes in finishCreationSubstring, we should resolve before passing it to JSRopeString.
1839         So that, we can access string data before creating JSRopeString, and we can introduce optimizations like avoiding creation
1840         of single character substrings.
1841
1842         We can find that a lot of substrings for length = 1 are allocated in RAMification regexp tests. This patch avoids creation of these
1843         strings to save memory.
1844
1845         This patch also strengthen error checks caused by rope resolution for base of substrings. Previously we sometimes miss this checks.
1846
1847         * dfg/DFGOperations.cpp:
1848         * runtime/JSString.cpp:
1849         (JSC::JSString::dumpToStream):
1850         * runtime/JSString.h:
1851         (JSC::jsSubstring):
1852         (JSC::jsSubstringOfResolved):
1853         (JSC::jsSingleCharacterString):
1854         * runtime/RegExpCachedResult.cpp:
1855         (JSC::RegExpCachedResult::lastResult): We no longer need to have length = 0 path since jsSubstring returns an empty string if length == 0.
1856         (JSC::RegExpCachedResult::leftContext):
1857         (JSC::RegExpCachedResult::rightContext):
1858         (JSC::RegExpCachedResult::setInput):
1859         * runtime/RegExpGlobalData.cpp:
1860         (JSC::RegExpGlobalData::getBackref):
1861         (JSC::RegExpGlobalData::getLastParen):
1862         * runtime/StringObject.h:
1863         (JSC::jsStringWithReuse):
1864         (JSC::jsSubstring):
1865         * runtime/StringPrototype.cpp:
1866         (JSC::replaceUsingRegExpSearch):
1867         (JSC::operationStringProtoFuncReplaceRegExpEmptyStr):
1868         (JSC::replaceUsingStringSearch):
1869         (JSC::stringProtoFuncSlice):
1870         (JSC::splitStringByOneCharacterImpl):
1871         (JSC::stringProtoFuncSplitFast):
1872         (JSC::stringProtoFuncSubstr):
1873         (JSC::stringProtoFuncSubstring):
1874         (JSC::stringProtoFuncToLowerCase):
1875         (JSC::stringProtoFuncToUpperCase):
1876         Some `const String& value = string->value(exec)` is dangerous if GC happens later. Changed to getting `String` instead of `const String&` here.
1877
1878         * runtime/StringPrototypeInlines.h:
1879         (JSC::stringSlice):
1880
1881 2019-03-18  Mark Lam  <mark.lam@apple.com>
1882
1883         Missing a ThrowScope release in JSObject::toString().
1884         https://bugs.webkit.org/show_bug.cgi?id=195893
1885         <rdar://problem/48970986>
1886
1887         Reviewed by Michael Saboff.
1888
1889         Placate the validator with a RELEASE_AND_RETURN().
1890
1891         * runtime/JSObject.cpp:
1892         (JSC::JSObject::toString const):
1893
1894 2019-03-18  Mark Lam  <mark.lam@apple.com>
1895
1896         Structure::flattenDictionary() should clear unused property slots.
1897         https://bugs.webkit.org/show_bug.cgi?id=195871
1898         <rdar://problem/48959497>
1899
1900         Reviewed by Michael Saboff.
1901
1902         It currently attempts to do this but fails because it's actually clearing up the
1903         preCapacity region instead.  The fix is simply to account for the preCapacity
1904         when computing the start address of the property slots.
1905
1906         * runtime/Structure.cpp:
1907         (JSC::Structure::flattenDictionaryStructure):
1908
1909 2019-03-18  Robin Morisset  <rmorisset@apple.com>
1910
1911         B3 should reduce Shl(<S|Z>Shr(@x, @const), @const) to BitAnd(@x, -(1<<@const))
1912         https://bugs.webkit.org/show_bug.cgi?id=152164
1913
1914         Reviewed by Filip Pizlo.
1915
1916         Turn this: Shl(<S|Z>Shr(@x, @const), @const)
1917         Into this: BitAnd(@x, -(1<<@const))
1918
1919         I added two tests: one for ZShr/32 bits, and one for SShr/64 bits, I think it is enough coverage (no reason for any interaction between the signedness of the shift and the bitwidth).
1920         I also modified a few adjacent tests to remove undefined behaviours.
1921
1922         * b3/B3ReduceStrength.cpp:
1923         * b3/testb3.cpp:
1924         (JSC::B3::testShlImms):
1925         (JSC::B3::testShlArgImm):
1926         (JSC::B3::testShlSShrArgImm):
1927         (JSC::B3::testShlImms32):
1928         (JSC::B3::testShlArgImm32):
1929         (JSC::B3::testShlZShrArgImm32):
1930         (JSC::B3::run):
1931
1932 2019-03-17  Robin Morisset  <rmorisset@apple.com>
1933
1934         ParserError can be shrunk by 8 bytes
1935         https://bugs.webkit.org/show_bug.cgi?id=195496
1936
1937         Reviewed by Mark Lam.
1938
1939         * parser/ParserError.h:
1940
1941 2019-03-17  Diego Pino Garcia  <dpino@igalia.com>
1942
1943         Fix WPE and GTK Debug builds after r243049
1944         https://bugs.webkit.org/show_bug.cgi?id=195860
1945
1946         Unreviewed, build fix after r243049.
1947
1948         * runtime/StringPrototype.cpp:
1949         (JSC::normalizationAffects8Bit):
1950
1951 2019-03-17  Yusuke Suzuki  <ysuzuki@apple.com>
1952
1953         REGRESSION: !vm.isInitializingObject() void* JSC::tryAllocateCellHelper<JSC::Structure> JSC::Structure::create
1954         https://bugs.webkit.org/show_bug.cgi?id=195858
1955
1956         Reviewed by Mark Lam.
1957
1958         r243011 changed WebAssembly related structures lazily-allocated. It means that this lazy allocation must not be done in the middle of
1959         the other object allocations. This patch changes the signature of wasm related objects' ::create functions to taking Structure*.
1960         This prevents us from materializing lazily-allocated structures while allocating wasm related objects, and this style is used in the
1961         other places to fix the same problem. This bug is caught by existing debug tests for wasm.
1962
1963         * runtime/JSGlobalObject.h:
1964         * wasm/js/JSWebAssemblyCompileError.cpp:
1965         (JSC::createJSWebAssemblyCompileError):
1966         * wasm/js/JSWebAssemblyInstance.cpp:
1967         (JSC::JSWebAssemblyInstance::finalizeCreation):
1968         (JSC::JSWebAssemblyInstance::create):
1969         * wasm/js/JSWebAssemblyLinkError.cpp:
1970         (JSC::createJSWebAssemblyLinkError):
1971         * wasm/js/JSWebAssemblyModule.cpp:
1972         (JSC::JSWebAssemblyModule::createStub):
1973         (JSC::JSWebAssemblyModule::finishCreation):
1974         * wasm/js/WasmToJS.cpp:
1975         (JSC::Wasm::wasmToJSException):
1976         * wasm/js/WebAssemblyCompileErrorConstructor.cpp:
1977         (JSC::constructJSWebAssemblyCompileError):
1978         (JSC::callJSWebAssemblyCompileError):
1979         * wasm/js/WebAssemblyFunction.cpp:
1980         (JSC::WebAssemblyFunction::create):
1981         * wasm/js/WebAssemblyFunction.h:
1982         * wasm/js/WebAssemblyInstanceConstructor.cpp:
1983         (JSC::constructJSWebAssemblyInstance):
1984         * wasm/js/WebAssemblyLinkErrorConstructor.cpp:
1985         (JSC::constructJSWebAssemblyLinkError):
1986         (JSC::callJSWebAssemblyLinkError):
1987         * wasm/js/WebAssemblyMemoryConstructor.cpp:
1988         (JSC::constructJSWebAssemblyMemory):
1989         * wasm/js/WebAssemblyModuleConstructor.cpp:
1990         (JSC::WebAssemblyModuleConstructor::createModule):
1991         * wasm/js/WebAssemblyModuleRecord.cpp:
1992         (JSC::WebAssemblyModuleRecord::link):
1993         (JSC::WebAssemblyModuleRecord::evaluate):
1994         * wasm/js/WebAssemblyPrototype.cpp:
1995         (JSC::webAssemblyModuleValidateAsyncInternal):
1996         (JSC::instantiate):
1997         (JSC::compileAndInstantiate):
1998         (JSC::webAssemblyModuleInstantinateAsyncInternal):
1999         * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
2000         (JSC::constructJSWebAssemblyRuntimeError):
2001         (JSC::callJSWebAssemblyRuntimeError):
2002         * wasm/js/WebAssemblyTableConstructor.cpp:
2003         (JSC::constructJSWebAssemblyTable):
2004         * wasm/js/WebAssemblyToJSCallee.cpp:
2005         (JSC::WebAssemblyToJSCallee::create):
2006         * wasm/js/WebAssemblyToJSCallee.h:
2007         * wasm/js/WebAssemblyWrapperFunction.cpp:
2008         (JSC::WebAssemblyWrapperFunction::create):
2009         * wasm/js/WebAssemblyWrapperFunction.h:
2010
2011 2019-03-16  Darin Adler  <darin@apple.com>
2012
2013         Improve normalization code, including moving from unorm.h to unorm2.h
2014         https://bugs.webkit.org/show_bug.cgi?id=195330
2015
2016         Reviewed by Michael Catanzaro.
2017
2018         * runtime/JSString.h: Move StringViewWithUnderlyingString to StringView.h.
2019
2020         * runtime/StringPrototype.cpp: Include unorm2.h instead of unorm.h.
2021         (JSC::normalizer): Added. Function to create normalizer object given
2022         enumeration value indicating which is selected. Simplified because we
2023         know the function will not fail and so we don't need error handling code.
2024         (JSC::normalize): Changed this function to take a JSString* so we can
2025         optimize the case where no normalization is needed. Added an early exit
2026         if the string is stored as 8-bit and another if the string is already
2027         normalized, using unorm2_isNormalized. Changed error handling to only
2028         check cases that can actually fail in practice. Also did other small
2029         optimizations like passing VM rather than ExecState.
2030         (JSC::stringProtoFuncNormalize): Used smaller enumeration names that are
2031         identical to the names used in the API and normalization parlance rather
2032         than longer ones that expand the acronyms. Updated to pass JSString* to
2033         the normalize function, so we can optimize 8-bit and already-normalized
2034         cases, rather than callling the expensive String::upconvertedCharacters
2035         function. Use throwVMRangeError.
2036
2037 2019-03-15  Mark Lam  <mark.lam@apple.com>
2038
2039         Need to check ObjectPropertyCondition liveness before accessing it when firing watchpoints.
2040         https://bugs.webkit.org/show_bug.cgi?id=195827
2041         <rdar://problem/48845513>
2042
2043         Reviewed by Filip Pizlo.
2044
2045         m_object in ObjectPropertyCondition may no longer be live by the time the watchpoint fires.
2046
2047         * bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp:
2048         (JSC::AdaptiveInferredPropertyValueWatchpointBase::fire):
2049         * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
2050         (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
2051         * bytecode/ObjectPropertyCondition.cpp:
2052         (JSC::ObjectPropertyCondition::dumpInContext const):
2053         * bytecode/StructureStubClearingWatchpoint.cpp:
2054         (JSC::StructureStubClearingWatchpoint::fireInternal):
2055         * dfg/DFGAdaptiveStructureWatchpoint.cpp:
2056         (JSC::DFG::AdaptiveStructureWatchpoint::fireInternal):
2057         * runtime/StructureRareData.cpp:
2058         (JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal):
2059
2060 2019-03-15  Yusuke Suzuki  <ysuzuki@apple.com>
2061
2062         [JSC] Make more properties lazily-allocated in JSGlobalObject, including properties only used in JIT mode
2063         https://bugs.webkit.org/show_bug.cgi?id=195816
2064
2065         Reviewed by Michael Saboff.
2066
2067         This patch makes more properties lazily-allocated in JSGlobalObject. This patch makes the following lazily-allocated.
2068
2069         1. iteratorResultObjectStructure
2070         2. WebAssembly related objects except for JSWebAssembly top-level object.
2071
2072         * CMakeLists.txt:
2073         * DerivedSources-input.xcfilelist:
2074         * DerivedSources-output.xcfilelist:
2075         * DerivedSources.make:
2076         * runtime/JSGlobalObject.cpp:
2077         (JSC::JSGlobalObject::init):
2078         (JSC::JSGlobalObject::visitChildren):
2079         * runtime/JSGlobalObject.h:
2080         (JSC::JSGlobalObject::iteratorResultObjectStructure const):
2081         (JSC::JSGlobalObject::webAssemblyModuleRecordStructure const):
2082         (JSC::JSGlobalObject::webAssemblyFunctionStructure const):
2083         (JSC::JSGlobalObject::webAssemblyWrapperFunctionStructure const):
2084         (JSC::JSGlobalObject::webAssemblyToJSCalleeStructure const):
2085         * wasm/js/JSWebAssembly.cpp:
2086         * wasm/js/JSWebAssembly.h:
2087
2088 2019-03-15  Dominik Infuehr  <dinfuehr@igalia.com>
2089
2090         [CMake] Move test .js files into testapiScripts
2091         https://bugs.webkit.org/show_bug.cgi?id=195565
2092
2093         Reviewed by Yusuke Suzuki.
2094
2095         testapi expect .js file in the testapiScripts-directory.
2096
2097         * shell/CMakeLists.txt:
2098
2099 2019-03-15  Mark Lam  <mark.lam@apple.com>
2100
2101         Gardening: add a missing exception check after r242991.
2102         https://bugs.webkit.org/show_bug.cgi?id=195791
2103
2104         Unreviewed.
2105
2106         * tools/JSDollarVM.cpp:
2107         (JSC::functionGetGetterSetter):
2108
2109 2019-03-15  Devin Rousso  <drousso@apple.com>
2110
2111         Web Inspector: provide a way to capture a screenshot of a node from within the page
2112         https://bugs.webkit.org/show_bug.cgi?id=194279
2113         <rdar://problem/10731573>
2114
2115         Reviewed by Joseph Pecoraro.
2116
2117         Add `console.screenshot` functionality, which displays a screenshot of a given object (if
2118         able) within Web Inspector's Console tab. From there, it can be viewed and saved.
2119
2120         Currently, `console.screenshot` will
2121          - capture an image of a `Node` (if provided)
2122          - capture an image of the viewport if nothing is provided
2123
2124         * inspector/protocol/Console.json:
2125         Add `Image` enum value to `ConsoleMessage` type.
2126         * runtime/ConsoleTypes.h:
2127         * inspector/ConsoleMessage.h:
2128         * inspector/ConsoleMessage.cpp:
2129         (Inspector::messageTypeValue):
2130
2131         * runtime/ConsoleClient.h:
2132         * runtime/ConsoleObject.cpp:
2133         (JSC::ConsoleObject::finishCreation):
2134         (JSC::consoleProtoFuncScreenshot): Added.
2135
2136         * inspector/JSGlobalObjectConsoleClient.h:
2137         * inspector/JSGlobalObjectConsoleClient.cpp:
2138         (Inspector::JSGlobalObjectConsoleClient::screenshot): Added.
2139
2140 2019-03-14  Yusuke Suzuki  <ysuzuki@apple.com>
2141
2142         [JSC] Retain PrivateName of Symbol before passing it to operations potentially incurring GC
2143         https://bugs.webkit.org/show_bug.cgi?id=195791
2144         <rdar://problem/48806130>
2145
2146         Reviewed by Mark Lam.
2147
2148         Consider the following example:
2149
2150             void putByVal(JSObject*, PropertyName propertyName, ...);
2151
2152             putByVal(object, symbol->privateName(), ...);
2153
2154         PropertyName does not retain the passed UniquedStringImpl*. It just holds the pointer to UniquedStringImpl*.
2155         It means that since `Symbol::privateName()` returns `const PrivateName&` instead of `PrivateName`, putByVal
2156         and its caller does not retain UniquedStringImpl* held in PropertyName. The problem happens when the putByVal
2157         incurs GC, and when the `symbol` is missing in the conservative GC scan. The underlying UniquedStringImpl* of
2158         PropertyName can be accidentally destroyed in the middle of the putByVal operation. We should retain PrivateName
2159         before passing it to operations which takes it as PropertyName.
2160
2161         1. We use the code pattern like this.
2162
2163             auto propertyName = symbol->privateName();
2164             someOperation(..., propertyName);
2165
2166         This pattern is well aligned to existing `JSValue::toPropertyKey(exec)` and `JSString::toIdentifier(exec)` code patterns.
2167
2168             auto propertyName = value.toPropertyKey(exec);
2169             RETURN_IF_EXCEPTION(scope, { });
2170             someOperation(..., propertyName);
2171
2172         2. We change `Symbol::privateName()` to returning `PrivateName` instead of `const PrivateName&` to avoid
2173            potential dangerous use cases. This is OK because the code using `Symbol::privateName()` is not a critical path,
2174            and they typically need to retain PrivateName.
2175
2176         3. We audit similar functions `toPropertyKey(exec)` and `toIdentifier(exec)` for needed but missing exception checks.
2177            BTW, these functions are safe to the problem fixed in this patch since they return `Identifier` instead
2178            of `const Identifier&`.
2179
2180         Mark and Robin investigated and offered important data to understand what went wrong. And figured out the reason behind
2181         the mysterious behavior shown in the data, and now, we confirm that this is the right fix for this bug.
2182
2183         * dfg/DFGOperations.cpp:
2184         * jit/JITOperations.cpp:
2185         (JSC::tryGetByValOptimize):
2186         * runtime/JSFunction.cpp:
2187         (JSC::JSFunction::setFunctionName):
2188         * runtime/JSModuleLoader.cpp:
2189         (JSC::printableModuleKey):
2190         * runtime/JSONObject.cpp:
2191         (JSC::Stringifier::Stringifier):
2192         * runtime/Symbol.cpp:
2193         (JSC::Symbol::descriptiveString const):
2194         (JSC::Symbol::description const):
2195         * runtime/Symbol.h:
2196         * runtime/SymbolConstructor.cpp:
2197         (JSC::symbolConstructorKeyFor):
2198         * tools/JSDollarVM.cpp:
2199         (JSC::functionGetGetterSetter):
2200
2201 2019-03-14  Yusuke Suzuki  <ysuzuki@apple.com>
2202
2203         REGRESSION(r242841): Fix conservative DFG OSR entry validation to accept values which will be stored in AnyInt / Double flush formats
2204         https://bugs.webkit.org/show_bug.cgi?id=195752
2205
2206         Reviewed by Saam Barati.
2207
2208         We fixed the bug skipping AbstractValue validations when the flush format is Double or AnyInt. But it
2209         was too conservative. While validating inputs with AbstractValue is mandatory (without it, whole CFA
2210         falls into wrong condition), our validation does not care AnyInt and Double representations in lower
2211         tiers. For example, if a value is stored in Double flush format in DFG, its AbstractValue becomes
2212         SpecFullDouble. However, it does not include Int32 and OSR entry is rejected if Int32 comes for DoubleRep
2213         OSR entry value. This is wrong since we later convert these numbers into DoubleRep representation
2214         before entering DFG code.
2215
2216         This patch performs AbstractValue validation onto the correctly converted value with flush format hint.
2217
2218         And it still does not fix OSR entry failures in navier-stokes. This is because AbstractValue representation
2219         in navier-stokes's lin_solve was too strict. Then, this patch reverts r242627. Instead of removing must handle
2220         value handling in CFA, DFG OSR entry now correctly validates inputs with AbstractValues even if the flush format
2221         is Double or AnyInt. As long as DFG OSR entry validates inputs, merging must handle values as proven constants is OK.
2222
2223         We can see that # of OSR entry failures in navier-stokes.js becomes the same to the previous count. And we can see
2224         AnyInt OSR entry actually works in microbenchmarks/large-int.js. However, AnyInt effect is hard to observe because this
2225         is super rare. Since we inject type prediction based on must handle value, the flush format tends to be SpecAnyIntAsDouble
2226         and it accepts JSValues simply.
2227
2228         * bytecode/SpeculatedType.cpp:
2229         (JSC::dumpSpeculation):
2230         * dfg/DFGAbstractValue.cpp:
2231         (JSC::DFG::AbstractValue::filterValueByType):
2232         * dfg/DFGAbstractValue.h:
2233         (JSC::DFG::AbstractValue::validateOSREntryValue const):
2234         (JSC::DFG::AbstractValue::validateTypeAcceptingBoxedInt52 const):
2235         (JSC::DFG::AbstractValue::validate const): Deleted.
2236         (JSC::DFG::AbstractValue::validateType const): Deleted.
2237         * dfg/DFGCFAPhase.cpp:
2238         (JSC::DFG::CFAPhase::run):
2239         (JSC::DFG::CFAPhase::injectOSR):
2240         (JSC::DFG::CFAPhase::performBlockCFA):
2241         * dfg/DFGOSREntry.cpp:
2242         (JSC::DFG::prepareOSREntry):
2243
2244 2019-03-14  Saam barati  <sbarati@apple.com>
2245
2246         We can't remove code after ForceOSRExit until after FixupPhase
2247         https://bugs.webkit.org/show_bug.cgi?id=186916
2248         <rdar://problem/41396612>
2249
2250         Reviewed by Yusuke Suzuki.
2251
2252         There was an optimization in the bytecode parser I added in r232742 that converted blocks
2253         with ForceOSRExit in them to remove all IR after the ForceOSRExit. However,
2254         this is incorrect because it breaks backwards propagation. For example, it
2255         could incorrectly lead us to think it's safe to not check for overflow in
2256         an Add because such Add has no non-int uses. Backwards propagation relies on
2257         having a view over bytecode uses, and this optimization broke that. This patch
2258         rolls out that optimization, as initial perf data shows it may no longer be
2259         needed.
2260
2261         * dfg/DFGByteCodeParser.cpp:
2262         (JSC::DFG::ByteCodeParser::addToGraph):
2263         (JSC::DFG::ByteCodeParser::parse):
2264
2265 2019-03-14  Saam barati  <sbarati@apple.com>
2266
2267         JSScript should have an accessor saying if it's cached or not
2268         https://bugs.webkit.org/show_bug.cgi?id=195783
2269
2270         Reviewed by Michael Saboff.
2271
2272         * API/JSScript.h:
2273         * API/JSScript.mm:
2274         (-[JSScript isUsingBytecodeCache]):
2275         * API/tests/testapi.mm:
2276         (testIsUsingBytecodeCacheAccessor):
2277         (testObjectiveCAPI):
2278
2279 2019-03-14  Saam barati  <sbarati@apple.com>
2280
2281         Remove retain cycle from JSScript and also don't keep the cache file descriptor open so many JSScripts can be cached in a loop
2282         https://bugs.webkit.org/show_bug.cgi?id=195782
2283         <rdar://problem/48880625>
2284
2285         Reviewed by Michael Saboff.
2286
2287         This patch fixes two issues with JSScript API:
2288         
2289         1. There was a retain cycle causing us to never destroy a JSScript once it
2290         created a JSSourceCode. The reason for this is that JSScript had a 
2291         Strong<JSSourceCode> field. And JSSourceCode transitively had RetainPtr<JSScript>.
2292         
2293         This patch fixes this issue by making the "jsSourceCode" accessor return a transient object.
2294         
2295         2. r242585 made it so that JSScript would keep the cache file descriptor open
2296         (and locked) for the duration of the lifetime of the JSScript itself. Our
2297         anticipation here is that it would make implementing iterative cache updates
2298         easier. However, this made using the API super limiting in other ways. For
2299         example, if a program had a loop that cached 3000 different JSScripts, it's
2300         likely that such a program would exhaust the open file count limit. This patch
2301         reverts to the behavior prior to r242585 where we just keep open the file descriptor
2302         while we read or write it.
2303
2304         * API/JSAPIGlobalObject.mm:
2305         (JSC::JSAPIGlobalObject::moduleLoaderFetch):
2306         * API/JSContext.mm:
2307         (-[JSContext evaluateJSScript:]):
2308         * API/JSScript.mm:
2309         (-[JSScript dealloc]):
2310         (-[JSScript readCache]):
2311         (-[JSScript init]):
2312         (-[JSScript sourceCode]):
2313         (-[JSScript jsSourceCode]):
2314         (-[JSScript writeCache:]):
2315         (-[JSScript forceRecreateJSSourceCode]): Deleted.
2316         * API/JSScriptInternal.h:
2317         * API/tests/testapi.mm:
2318         (testCanCacheManyFilesWithTheSameVM):
2319         (testObjectiveCAPI):
2320         (testCacheFileIsExclusive): Deleted.
2321
2322 2019-03-14  Michael Saboff  <msaboff@apple.com>
2323
2324         ASSERTION FAILED: regexp->isValid() or ASSERTION FAILED: !isCompilationThread()
2325         https://bugs.webkit.org/show_bug.cgi?id=195735
2326
2327         Reviewed by Mark Lam.
2328
2329         There are two bug fixes here.
2330
2331         The first bug happens due to a race condition when we are compiling on a separate thread while the
2332         main thread is compiling the RegExp at a place where it can run out of stack.  When that happens,
2333         the RegExp becomes invalid due to the out of stack error.  If we check the ASSERT condition in the DFG
2334         compilation thread, we crash.  After the main thread throws an exception, it resets the RegExp as
2335         it might compile successfully the next time we try to execute it on a shallower stack.
2336         The main thread will see the regular expression as valid when it executes the JIT'ed code we are compiling
2337         or any slow path we call out to.  Therefore ASSERTs like this in compilation code can be eliminated.
2338
2339         The second bug is due to incorrect logic when we go to run the regexp in the Strength Reduction phase.
2340         The current check for "do we have code to run the RegExp?" only checks that the RegExp's state
2341         is != NotCompiled.  We also can't run the RegExp if there the state is ParseError.
2342         Changing hasCode() to take this into account fixes the second issue.
2343
2344         (JSC::FTL::DFG::LowerDFGToB3::compileNewRegexp):
2345         * runtime/RegExp.h:
2346         * dfg/DFGSpeculativeJIT.cpp:
2347         (JSC::DFG::SpeculativeJIT::compileNewRegexp):
2348         * runtime/RegExp.h:
2349
2350 2019-03-14  Saam barati  <sbarati@apple.com>
2351
2352         Fixup uses KnownInt32 incorrectly in some nodes
2353         https://bugs.webkit.org/show_bug.cgi?id=195279
2354         <rdar://problem/47915654>
2355
2356         Reviewed by Yusuke Suzuki.
2357
2358         Fixup was sometimes using KnownInt32 edges when it knew some
2359         incoming value is an Int32 based on what the bytecode would return.
2360         However, because bytecode may result in Int32 for some node does
2361         not mean we'll pick Int32 as the value format for that local. For example,
2362         we may choose for a value to be represented as a double. This patch
2363         corrects such uses of KnownInt32.
2364
2365         * dfg/DFGArgumentsEliminationPhase.cpp:
2366         * dfg/DFGFixupPhase.cpp:
2367         (JSC::DFG::FixupPhase::fixupNode):
2368         * dfg/DFGSpeculativeJIT.cpp:
2369         (JSC::DFG::SpeculativeJIT::compileArrayPush):
2370         (JSC::DFG::SpeculativeJIT::compileGetDirectPname):
2371         * ftl/FTLLowerDFGToB3.cpp:
2372         (JSC::FTL::DFG::LowerDFGToB3::compileArrayPush):
2373
2374 2019-03-14  Keith Miller  <keith_miller@apple.com>
2375
2376         DFG liveness can't skip tail caller inline frames
2377         https://bugs.webkit.org/show_bug.cgi?id=195715
2378         <rdar://problem/46221598>
2379
2380         Reviewed by Saam Barati.
2381
2382         In order to simplify OSR exit/DFG bytecode parsing our bytecode
2383         generator always emits an op_ret after any tail call. However, the
2384         DFG when computing the liveness of locals, would skip any tail
2385         caller inline frames. This mean that if we ended up inserting a
2386         Check that would OSR to the op_ret we wouldn't have kept
2387         availability data around for it.
2388
2389         * dfg/DFGGraph.cpp:
2390         (JSC::DFG::Graph::isLiveInBytecode):
2391         * dfg/DFGGraph.h:
2392         (JSC::DFG::Graph::forAllLocalsLiveInBytecode):
2393
2394 2019-03-14  Robin Morisset  <rmorisset@apple.com>
2395
2396         DFG::Worklist can be shrunk by 16 bytes
2397         https://bugs.webkit.org/show_bug.cgi?id=195490
2398
2399         Reviewed by Darin Adler.
2400
2401         * dfg/DFGWorklist.cpp:
2402         (JSC::DFG::Worklist::Worklist):
2403         * dfg/DFGWorklist.h:
2404
2405 2019-03-14  Devin Rousso  <drousso@apple.com>
2406
2407         Web Inspector: Audit: provide a way to get the contents of resources
2408         https://bugs.webkit.org/show_bug.cgi?id=195266
2409         <rdar://problem/48550911>
2410
2411         Reviewed by Joseph Pecoraro.
2412
2413         * inspector/InjectedScriptBase.cpp:
2414         (Inspector::InjectedScriptBase::makeAsyncCall):
2415         Drive-by: fix missing `else`.
2416
2417 2019-03-14  Devin Rousso  <drousso@apple.com>
2418
2419         Web Inspector: Styles: `::-webkit-scrollbar*` rules aren't shown
2420         https://bugs.webkit.org/show_bug.cgi?id=195123
2421         <rdar://problem/48450148>
2422
2423         Reviewed by Joseph Pecoraro.
2424
2425         * inspector/protocol/CSS.json:
2426         Add `CSS.PseudoId` enum, rather than send a number, so that we have more knowledge about
2427         which pseudo type the rule corresponds to (e.g. a string is more descriptive than a number).
2428
2429 2019-03-13  Caio Lima  <ticaiolima@gmail.com>
2430
2431         [JSC] CodeBlock::visitChildren is reporting extra memory even when its JITCode is singleton
2432         https://bugs.webkit.org/show_bug.cgi?id=195638
2433
2434         Reviewed by Mark Lam.
2435
2436         This patch introduces a m_isShared flag to track whether the
2437         JITCode is shared between many CodeBlocks. This flag is used in
2438         `CodeBlock::setJITCode` and `CodeBlock::visitChildren` to avoid
2439         reporting duplicated extra memory for singleton JITCodes.
2440         With those changes, we now stop counting singleton LLIntEntrypoints
2441         as extra memory, since they are declared as static variables. This
2442         change can potentially avoid unecessary GC pressure, because
2443         extra memory is used by Heap::updateAllocationLimits() to update Heap
2444         limits.
2445         Even though it is hard to show performance difference for this change
2446         (see results below), it is important to keep extra memory usage
2447         correct. Otherwise, it can be a source of a complicated bug on
2448         GC in the future.
2449
2450         Results from last run of Speedometer 2 comparing ToT and changes. We
2451         collected those numbers running Minibrowser on a MacBook Pro 15-inch
2452         with 2,6 GHz Intel Core i7. Both versions are with JIT disabled,
2453         since these singleton JITCode are only used by this configuration:
2454
2455         Speedometer2 Run #1
2456             ToT: 58.2 +- 1.1
2457             changes: 57.9 +- 0.99
2458
2459         Speedometer2 Run #2
2460             ToT: 58.5 +- 1.7
2461             changes: 58.0 +- 1.5
2462
2463         Speedometer2 Run #2
2464             ToT: 58.5 +- 0.99
2465             changes: 57.1 +- 1.5
2466
2467         * bytecode/CodeBlock.cpp:
2468         (JSC::CodeBlock::estimatedSize):
2469         (JSC::CodeBlock::visitChildren):
2470         * bytecode/CodeBlock.h:
2471         (JSC::CodeBlock::setJITCode):
2472         * jit/JITCode.cpp:
2473         (JSC::JITCode::JITCode):
2474         (JSC::JITCodeWithCodeRef::JITCodeWithCodeRef):
2475         (JSC::DirectJITCode::DirectJITCode):
2476         (JSC::NativeJITCode::NativeJITCode):
2477         * jit/JITCode.h:
2478         (JSC::JITCode::isShared const):
2479         * llint/LLIntEntrypoint.cpp:
2480         (JSC::LLInt::setFunctionEntrypoint):
2481         (JSC::LLInt::setEvalEntrypoint):
2482         (JSC::LLInt::setProgramEntrypoint):
2483         (JSC::LLInt::setModuleProgramEntrypoint):
2484
2485 2019-03-13  Keith Rollin  <krollin@apple.com>
2486
2487         Add support for new StagedFrameworks layout
2488         https://bugs.webkit.org/show_bug.cgi?id=195543
2489
2490         Reviewed by Alexey Proskuryakov.
2491
2492         When creating the WebKit layout for out-of-band Safari/WebKit updates,
2493         use an optional path prefix when called for.
2494
2495         * Configurations/Base.xcconfig:
2496
2497 2019-03-13  Mark Lam  <mark.lam@apple.com>
2498
2499         Remove unneeded --tradeDestructorBlocks option.
2500         https://bugs.webkit.org/show_bug.cgi?id=195698
2501         <rdar://problem/39681388>
2502
2503         Reviewed by Yusuke Suzuki.
2504
2505         There's no reason why we would ever want --tradeDestructorBlocks to be false.
2506
2507         Also, there was an assertion in BlockDirectory::endMarking() for when
2508         (!Options::tradeDestructorBlocks() && needsDestruction()).  This assertion is
2509         outdated because the BlockDirectory's m_empty set used to mean the set of all
2510         blocks that have no live (as in not reachable by GC) objects and dead objects
2511         also do not require destructors to be called on them.  The current meaning of
2512         m_empty is that it is the set of all blocks that have no live objects,
2513         independent of whether they needs destructors to be called on them or not.
2514         The assertion is no longer valid for the new meaning of m_empty as m_empty may
2515         now contain destructible blocks.  This assertion is now removed as part of this
2516         patch.
2517
2518         * heap/BlockDirectory.cpp:
2519         (JSC::BlockDirectory::endMarking):
2520         * heap/LocalAllocator.cpp:
2521         (JSC::LocalAllocator::tryAllocateWithoutCollecting):
2522         * runtime/Options.h:
2523
2524 2019-03-13  Dominik Infuehr  <dinfuehr@igalia.com>
2525
2526         String overflow when using StringBuilder in JSC::createError
2527         https://bugs.webkit.org/show_bug.cgi?id=194957
2528
2529         Reviewed by Mark Lam.
2530
2531         StringBuilder in notAFunctionSourceAppender didn't check
2532         for overflows but just failed.
2533
2534         * runtime/ExceptionHelpers.cpp:
2535         (JSC::notAFunctionSourceAppender):
2536
2537 2019-03-11  Yusuke Suzuki  <ysuzuki@apple.com>
2538
2539         [JSC] Move species watchpoint installation from ArrayPrototype to JSGlobalObject
2540         https://bugs.webkit.org/show_bug.cgi?id=195593
2541
2542         Reviewed by Keith Miller.
2543
2544         This patch moves watchpoints installation and watchpoints themselves from ArrayPrototype to JSGlobalObject because of the following two reasons.
2545
2546         1. ArrayPrototype configures finalizer because of std::unique_ptr<> for watchpoints. If we move them from ArrayPrototype to JSGlobalObject, we do
2547            not need to set finalizer. And we can avoid unnecessary WeakBlock allocation.
2548
2549         2. This code lazily configures watchpoints instead of setting watchpoints eagerly in JSGlobalObject::init. We would like to expand this mechanism
2550            to other watchpoints which are eagerly configured in JSGlobalObject::init. Putting these code in JSGlobalObject instead of scattering them in
2551            each XXXPrototype / XXXConstructor can encourage the reuse of the code.
2552
2553         * runtime/ArrayPrototype.cpp:
2554         (JSC::ArrayPrototype::create):
2555         (JSC::speciesWatchpointIsValid):
2556         (JSC::ArrayPrototype::destroy): Deleted.
2557         (JSC::ArrayPrototype::tryInitializeSpeciesWatchpoint): Deleted.
2558         (JSC::ArrayPrototypeAdaptiveInferredPropertyWatchpoint::ArrayPrototypeAdaptiveInferredPropertyWatchpoint): Deleted.
2559         (JSC::ArrayPrototypeAdaptiveInferredPropertyWatchpoint::handleFire): Deleted.
2560         * runtime/ArrayPrototype.h:
2561         * runtime/JSGlobalObject.cpp:
2562         (JSC::JSGlobalObject::tryInstallArraySpeciesWatchpoint): Instead of using ArrayPrototypeAdaptiveInferredPropertyWatchpoint,
2563         we use ObjectPropertyChangeAdaptiveWatchpoint. We create watchpoints after touching WatchpointSet since ObjectPropertyChangeAdaptiveWatchpoint
2564         requires WatchpointSet is IsWatched state.
2565         * runtime/JSGlobalObject.h:
2566
2567 2019-03-12  Yusuke Suzuki  <ysuzuki@apple.com>
2568
2569         [JSC] OSR entry should respect abstract values in addition to flush formats
2570         https://bugs.webkit.org/show_bug.cgi?id=195653
2571
2572         Reviewed by Mark Lam.
2573
2574         Let's consider the following graph.
2575
2576         Block #0
2577             ...
2578             27:< 2:loc13> JSConstant(JS|UseAsOther, StringIdent, Strong:String (atomic) (identifier): , StructureID: 42679, bc#10, ExitValid)
2579             ...
2580             28:< 2:loc13> ArithPow(DoubleRep:@437<Double>, Int32:@27, Double|UseAsOther, BytecodeDouble, Exits, bc#10, ExitValid)
2581             29:<!0:->     MovHint(DoubleRep:@28<Double>, MustGen, loc7, W:SideState, ClobbersExit, bc#10, ExitValid)
2582             30:< 1:->     SetLocal(DoubleRep:@28<Double>, loc7(M<Double>/FlushedDouble), machine:loc6, W:Stack(-8), bc#10, exit: bc#14, ExitValid)  predicting BytecodeDouble
2583             ...
2584             73:<!0:->     Jump(MustGen, T:#1, W:SideState, bc#71, ExitValid)
2585
2586         Block #1 (bc#71): (OSR target) pred, #0
2587             ...
2588            102:<!2:loc15> GetLocal(Check:Untyped:@400, Double|MustGen|PureInt, BytecodeDouble, loc7(M<Double>/FlushedDouble), machine:loc6, R:Stack(-8), bc#120, ExitValid)  predicting BytecodeDouble
2589             ...
2590
2591         CFA at @28 says it is invalid since there are type contradiction (Int32:@27 v.s. StringIdent). So, of course, we do not propagate #0's type information to #1 since we become invalid state.
2592         However, #1 is still reachable since it is an OSR target. Since #0 was only the predecessor of #1, loc7's type information becomes None at the head of #1.
2593         Since loc7's AbstractValue is None, @102 GetLocal emits breakpoint. It is OK as long as OSR entry fails because AbstractValue validation requires the given value is None type.
2594
2595         The issue here is that we skipped AbstractValue validation when we have FlushFormat information. Since loc7 has FlushedDouble format, DFG OSR entry code does not validate it against AbstractValue,
2596         which is None. Then, we hit the breakpoint emitted by @102.
2597
2598         This patch performs AbstractValue validation against values even if we have FlushFormat. We should correctly configure AbstractValue for OSR entry's locals too to avoid unnecessary OSR entry
2599         failures in the future but anyway validating locals with AbstractValue is correct behavior here since DFGSpeculativeJIT relies on that.
2600
2601         * dfg/DFGOSREntry.cpp:
2602         (JSC::DFG::prepareOSREntry):
2603
2604 2019-03-12  Michael Saboff  <msaboff@apple.com>
2605
2606         REGRESSION (iOS 12.2): Webpage using CoffeeScript crashes
2607         https://bugs.webkit.org/show_bug.cgi?id=195613
2608
2609         Reviewed by Mark Lam.
2610
2611         The bug here is in Yarr JIT backreference matching code.  We are incorrectly
2612         using a checkedOffset / inputPosition correction when checking for the available
2613         length left in a string.  It is improper to do these corrections as a backreference's
2614         match length is based on what was matched in the referenced capture group and not
2615         part of the checkedOffset and inputPosition computed when we compiled the RegExp.
2616         In some cases, the resulting incorrect calculation would allow us to go past
2617         the subject string's length.  Removed these adjustments.
2618
2619         After writing tests for the first bug, found another bug where the non-greedy
2620         backreference backtracking code didn't do an "are we at the end of the input?" check.
2621         This caused an infinite loop as we'd jump from the backtracking code back to
2622         try matching one more backreference, fail and then backtrack.
2623
2624         * yarr/YarrJIT.cpp:
2625         (JSC::Yarr::YarrGenerator::generateBackReference):
2626         (JSC::Yarr::YarrGenerator::backtrackBackReference):
2627
2628 2019-03-12  Robin Morisset  <rmorisset@apple.com>
2629
2630         A lot more classes have padding that can be reduced by reordering their fields
2631         https://bugs.webkit.org/show_bug.cgi?id=195579
2632
2633         Reviewed by Mark Lam.
2634
2635         * assembler/LinkBuffer.h:
2636         * dfg/DFGArrayifySlowPathGenerator.h:
2637         (JSC::DFG::ArrayifySlowPathGenerator::ArrayifySlowPathGenerator):
2638         * dfg/DFGCallArrayAllocatorSlowPathGenerator.h:
2639         (JSC::DFG::CallArrayAllocatorSlowPathGenerator::CallArrayAllocatorSlowPathGenerator):
2640         (JSC::DFG::CallArrayAllocatorWithVariableSizeSlowPathGenerator::CallArrayAllocatorWithVariableSizeSlowPathGenerator):
2641         * dfg/DFGGraph.h:
2642         * dfg/DFGNode.h:
2643         (JSC::DFG::SwitchData::SwitchData):
2644         * dfg/DFGPlan.cpp:
2645         (JSC::DFG::Plan::Plan):
2646         * dfg/DFGPlan.h:
2647         * dfg/DFGSlowPathGenerator.h:
2648         (JSC::DFG::CallSlowPathGenerator::CallSlowPathGenerator):
2649         * dfg/DFGSpeculativeJIT.cpp:
2650         (JSC::DFG::SpeculativeJIT::SpeculativeJIT):
2651         * dfg/DFGSpeculativeJIT.h:
2652         * domjit/DOMJITSignature.h:
2653         (JSC::DOMJIT::Signature::Signature):
2654         (JSC::DOMJIT::Signature::effect):
2655         (JSC::DOMJIT::Signature::argumentCount): Deleted.
2656         * heap/MarkingConstraintSolver.h:
2657         * heap/SlotVisitor.h:
2658         * jit/CallFrameShuffleData.h:
2659         * jit/JITDivGenerator.h:
2660         * jit/SpillRegistersMode.h:
2661         * parser/Nodes.h:
2662         * profiler/ProfilerOSRExit.cpp:
2663         (JSC::Profiler::OSRExit::OSRExit):
2664         * profiler/ProfilerOSRExit.h:
2665         * runtime/ArrayBufferView.h:
2666         * runtime/SamplingProfiler.cpp:
2667         (JSC::SamplingProfiler::SamplingProfiler):
2668         * runtime/SamplingProfiler.h:
2669         * runtime/TypeSet.cpp:
2670         (JSC::StructureShape::StructureShape):
2671         * runtime/TypeSet.h:
2672         * runtime/Watchdog.h:
2673
2674 2019-03-12  Mark Lam  <mark.lam@apple.com>
2675
2676         The HasIndexedProperty node does GC.
2677         https://bugs.webkit.org/show_bug.cgi?id=195559
2678         <rdar://problem/48767923>
2679
2680         Reviewed by Yusuke Suzuki.
2681
2682         HasIndexedProperty can call the slow path operationHasIndexedPropertyByInt(),
2683         which can eventually call JSString::getIndex(), which can resolve a rope.
2684
2685         * dfg/DFGDoesGC.cpp:
2686         (JSC::DFG::doesGC):
2687
2688 2019-03-12  Devin Rousso  <drousso@apple.com>
2689
2690         Web Inspector: Audit: there should be a centralized place for reusable code
2691         https://bugs.webkit.org/show_bug.cgi?id=195265
2692         <rdar://problem/47040673>
2693
2694         Reviewed by Joseph Pecoraro.
2695
2696         * inspector/protocol/Audit.json:
2697         Increment version.
2698
2699 2019-03-12  Robin Morisset  <rmorisset@apple.com>
2700
2701         blocksInPreOrder and blocksInPostOrder should reserve the right capacity for their result vector
2702         https://bugs.webkit.org/show_bug.cgi?id=195595
2703
2704         Reviewed by Saam Barati.
2705
2706         Also change BlockList from being Vector<BasicBlock*, 5> to Vector<BasicBlock*>
2707
2708         * dfg/DFGBasicBlock.h:
2709         * dfg/DFGGraph.cpp:
2710         (JSC::DFG::Graph::blocksInPreOrder):
2711         (JSC::DFG::Graph::blocksInPostOrder):
2712
2713 2019-03-11  Ross Kirsling  <ross.kirsling@sony.com>
2714
2715         Add Optional to Forward.h.
2716         https://bugs.webkit.org/show_bug.cgi?id=195586
2717
2718         Reviewed by Darin Adler.
2719
2720         * b3/B3Common.cpp:
2721         * b3/B3Common.h:
2722         * debugger/DebuggerParseData.cpp:
2723         * debugger/DebuggerParseData.h:
2724         * heap/HeapSnapshot.cpp:
2725         * heap/HeapSnapshot.h:
2726         * jit/PCToCodeOriginMap.cpp:
2727         * jit/PCToCodeOriginMap.h:
2728         * runtime/AbstractModuleRecord.cpp:
2729         * runtime/AbstractModuleRecord.h:
2730         * wasm/WasmInstance.h:
2731         * wasm/WasmModuleParser.h:
2732         * wasm/WasmSectionParser.cpp:
2733         * wasm/WasmSectionParser.h:
2734         * wasm/WasmStreamingParser.cpp:
2735         * wasm/WasmStreamingParser.h:
2736         * yarr/YarrFlags.cpp:
2737         * yarr/YarrFlags.h:
2738         * yarr/YarrUnicodeProperties.cpp:
2739         * yarr/YarrUnicodeProperties.h:
2740         Remove unnecessary includes from headers.
2741
2742 2019-03-11  Justin Fan  <justin_fan@apple.com>
2743
2744         [Web GPU] Update GPUSwapChainDescriptor, GPUSwapChain and implement GPUCanvasContext
2745         https://bugs.webkit.org/show_bug.cgi?id=194406
2746         <rdar://problem/47892466>
2747
2748         Reviewed by Myles C. Maxfield.
2749
2750         Added WebGPU to inspector context types.
2751
2752         * inspector/protocol/Canvas.json:
2753         * inspector/scripts/codegen/generator.py:
2754
2755 2019-03-11  Yusuke Suzuki  <ysuzuki@apple.com>
2756
2757         [JSC] Reduce # of structures in JSGlobalObject initialization
2758         https://bugs.webkit.org/show_bug.cgi?id=195498
2759
2760         Reviewed by Darin Adler.
2761
2762         This patch reduces # of structure allocations in JSGlobalObject initialization. Now it becomes 141, it fits in one
2763         MarkedBlock and this patch drops one MarkedBlock used for Structure previously.
2764
2765         * CMakeLists.txt:
2766         * DerivedSources-output.xcfilelist:
2767         * DerivedSources.make:
2768         * JavaScriptCore.xcodeproj/project.pbxproj:
2769         * runtime/ArrayIteratorPrototype.cpp:
2770         (JSC::ArrayIteratorPrototype::finishCreation): ArrayIteratorPrototype, MapIteratorPrototype, and StringIteratorPrototype's
2771         "next" properties are referenced by JSGlobalObject::init, and it causes reification of the lazy "next" property and structure
2772         transition anyway. So we should put it eagerly "without-transition" configuration to avoid one structure transition.
2773
2774         * runtime/ArrayPrototype.cpp:
2775         (JSC::ArrayPrototype::finishCreation): @@unscopable object's structure should be dictionary because (1) it is used as a dictionary
2776         in with-scope-resolution and (2) since with-scope-resolution is C++ runtime function anyway, non-dictionary structure does not add
2777         any performance benefit. This change saves several structures that are not useful.
2778
2779         * runtime/ClonedArguments.cpp:
2780         (JSC::ClonedArguments::createStructure): Bake CloneArguments's structure with 'without-transition' manner.
2781
2782         * runtime/JSGlobalObject.cpp:
2783         (JSC::JSGlobalObject::init): Previously we are always call resetProtoype at the end of JSGlobalObject::init. But it is not necessary
2784         since we do not change [[Prototype]] of JSGlobalObject. All we want is (1) fixupPrototypeChainWithObjectPrototype's operation and (2) setGlobalThis
2785         operation. Since setGlobalThis part is done in JSGlobalObject::finishCreation, fixupPrototypeChainWithObjectPrototype is only the thing
2786         we should do here.
2787
2788         (JSC::JSGlobalObject::fixupPrototypeChainWithObjectPrototype):
2789         (JSC::JSGlobalObject::resetPrototype): If the [[Prototype]] is the same to the current [[Prototype]], we can skip the operation.
2790
2791         * runtime/JSGlobalObject.h:
2792         * runtime/MapIteratorPrototype.cpp:
2793         (JSC::MapIteratorPrototype::finishCreation):
2794         * runtime/NullGetterFunction.h:
2795         * runtime/NullSetterFunction.h: Since structures of them are allocated per JSGlobalObject and they are per-JSGlobalObject,
2796         we can use without-transition property addition.
2797
2798         * runtime/StringIteratorPrototype.cpp:
2799         (JSC::StringIteratorPrototype::finishCreation):
2800         * runtime/VM.cpp:
2801         (JSC::VM::VM):
2802         (JSC::VM::setIteratorStructureSlow):
2803         (JSC::VM::mapIteratorStructureSlow): These structures are only used in WebCore's main thread.
2804         * runtime/VM.h:
2805         (JSC::VM::setIteratorStructure):
2806         (JSC::VM::mapIteratorStructure):
2807
2808 2019-03-08  Yusuke Suzuki  <ysuzuki@apple.com>
2809
2810         [JSC] BuiltinExecutables should behave like a WeakSet instead of generic WeakHandleOwner for memory footprint
2811         https://bugs.webkit.org/show_bug.cgi?id=195508
2812
2813         Reviewed by Darin Adler.
2814
2815         Weak<> is not cheap in terms of memory footprint. We allocate WeakBlock (256 bytes) for book-keeping Weak<>.
2816         Currently BuiltinExecutables has 203 Weak<> members and many WeakBlocks are actually allocated because
2817         many UnlinkedFunctionExecutables in BuiltinExecutables are allocated during JSGlobalObject initialization process.
2818
2819         This patch changes two things in BuiltinExecutables.
2820
2821         1. Previously we have m_xxxSourceCode fields too. But we do not need to keep it since we know how to produce it when it is required.
2822            We generate SourceCode in xxxSourceCode() method instead of just returning m_xxxSourceCode. This reduces sizeof(BuiltinExecutables) 24 x 203 = 4KB.
2823
2824         2. Instead of using Weak<>, BuiltinExecutables holds raw array of UnlinkedFunctionExecutable*. And Heap::finalizeUnconditionalFinalizers() correctly clears dead executables.
2825            This is similar to JSWeakSet implementation. And it saves WeakBlock allocations.
2826
2827         * builtins/BuiltinExecutables.cpp:
2828         (JSC::BuiltinExecutables::BuiltinExecutables):
2829         (JSC::BuiltinExecutables::finalizeUnconditionally):
2830         (JSC::JSC_FOREACH_BUILTIN_CODE): Deleted.
2831         (JSC::BuiltinExecutables::finalize): Deleted.
2832         * builtins/BuiltinExecutables.h:
2833         (JSC::BuiltinExecutables::static_cast<unsigned>):
2834         (): Deleted.
2835         * heap/Heap.cpp:
2836         (JSC::Heap::finalizeUnconditionalFinalizers):
2837
2838 2019-03-11  Robin Morisset  <rmorisset@apple.com>
2839
2840         IntlDateTimeFormat can be shrunk by 32 bytes
2841         https://bugs.webkit.org/show_bug.cgi?id=195504
2842
2843         Reviewed by Darin Adler.
2844
2845         * runtime/IntlDateTimeFormat.h:
2846
2847 2019-03-11  Robin Morisset  <rmorisset@apple.com>
2848
2849         IntlCollator can be shrunk by 16 bytes
2850         https://bugs.webkit.org/show_bug.cgi?id=195503
2851
2852         Reviewed by Darin Adler.
2853
2854         * runtime/IntlCollator.h:
2855
2856 2019-03-11  Robin Morisset  <rmorisset@apple.com>
2857
2858         IntlNumberFormat can be shrunk by 16 bytes
2859         https://bugs.webkit.org/show_bug.cgi?id=195505
2860
2861         Reviewed by Darin Adler.
2862
2863         * runtime/IntlNumberFormat.h:
2864
2865 2019-03-11  Caio Lima  <ticaiolima@gmail.com>
2866
2867         [ESNext][BigInt] Implement "~" unary operation
2868         https://bugs.webkit.org/show_bug.cgi?id=182216
2869
2870         Reviewed by Keith Miller.
2871
2872         This patch is adding support of BigInt into op_bitnot operations. In
2873         addition, we are changing ArithBitNot to handle only Number operands,
2874         while introducing a new node named ValueBitNot to handle Untyped and
2875         BigInt. This node follows the same approach we are doing into other
2876         arithimetic operations into DFG.
2877
2878         * dfg/DFGAbstractInterpreterInlines.h:
2879         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2880
2881         It is possible that fixup and prediction propagation don't convert a
2882         ValueBitNot(ConstInt32) into ArithBitNot(ConstInt32) because these
2883         analysis are conservative. In such case, we are adding constant
2884         folding rules to ValueBitNot AI.
2885
2886         * dfg/DFGBackwardsPropagationPhase.cpp:
2887         (JSC::DFG::BackwardsPropagationPhase::propagate):
2888
2889         ValueBitNot has same rules as ArithBitNot on backwards propagation.
2890
2891         * dfg/DFGByteCodeParser.cpp:
2892         (JSC::DFG::ByteCodeParser::parseBlock):
2893
2894         We can emit ArithBitNot if we know that operand of op_bitnot is a
2895         Number or any int. Otherwise we fallback to ValueBitNot and rely on
2896         fixup to convert the node to ArithBitNot when it is possible.
2897         ValueBitNot uses heap prediction on prediction propagation and we
2898         collect its type from op_bitnot's value profiler.
2899
2900         * dfg/DFGClobberize.h:
2901         (JSC::DFG::clobberize):
2902
2903         When we have the case with ValueBitNot(BigInt), we don't clobberize
2904         world.
2905
2906         * dfg/DFGDoesGC.cpp:
2907         (JSC::DFG::doesGC):
2908
2909         ValueBitNot can GC on BigIntUse because, right now, all bitNot
2910         operation allocates temporary BigInts to perform calculations and it
2911         can potentially trigger GC.
2912
2913         * dfg/DFGFixupPhase.cpp:
2914         (JSC::DFG::FixupPhase::fixupNode):
2915
2916         ValueBitNot is responsible do handle BigIntUse and UntypedUse. To all
2917         other uses, we fallback to ArithBitNot.
2918
2919         * dfg/DFGNode.h:
2920         (JSC::DFG::Node::hasHeapPrediction):
2921         * dfg/DFGNodeType.h:
2922         * dfg/DFGOperations.cpp:
2923         (JSC::DFG::bitwiseBinaryOp):
2924
2925         This template function is abstracting the new semantics of numeric
2926         values operations on bitwise operations. These operations usually
2927         folow these steps:
2928
2929             1. rhsNumeric = GetInt32OrBigInt(rhs)
2930             2. lhsNumeric = GetInt32OrBigInt(lhs)
2931             3. trhow error if TypeOf(rhsNumeric) != TypeOf(lhsNumeric)
2932             4. return BigInt::bitwiseOp(bitOp, rhs, lhs) if TypeOf(lhsNumeric) == BigInt
2933             5. return rhs <int32BitOp> lhs
2934
2935         Since we have almost the same code for every bitwise op,
2936         we use such template to avoid code duplication. The template receives
2937         Int32 and BigInt operations as parameter. Error message is received as
2938         `const char*` instead of `String&` to avoid String allocation even when
2939         there is no error to throw.
2940
2941         * dfg/DFGOperations.h:
2942         * dfg/DFGPredictionPropagationPhase.cpp:
2943         * dfg/DFGSafeToExecute.h:
2944         (JSC::DFG::safeToExecute):
2945         * dfg/DFGSpeculativeJIT.cpp:
2946         (JSC::DFG::SpeculativeJIT::compileValueBitNot):
2947
2948         ValueBitNot generates speculative code for BigIntUse and this code is a
2949         call to `operationBitNotBigInt`. This operation is faster than
2950         `operationValueBitNot` because there is no need to check types of
2951         operands and execute properly operation. We still need to check
2952         exceptions after `operationBitNotBigInt` because it can throw OOM.
2953
2954         (JSC::DFG::SpeculativeJIT::compileBitwiseNot):
2955         * dfg/DFGSpeculativeJIT.h:
2956         * dfg/DFGSpeculativeJIT32_64.cpp:
2957         (JSC::DFG::SpeculativeJIT::compile):
2958         * dfg/DFGSpeculativeJIT64.cpp:
2959         (JSC::DFG::SpeculativeJIT::compile):
2960         * ftl/FTLCapabilities.cpp:
2961         (JSC::FTL::canCompile):
2962         * ftl/FTLLowerDFGToB3.cpp:
2963         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2964         (JSC::FTL::DFG::LowerDFGToB3::compileValueBitNot):
2965         (JSC::FTL::DFG::LowerDFGToB3::compileArithBitNot):
2966         * runtime/CommonSlowPaths.cpp:
2967         (JSC::SLOW_PATH_DECL):
2968         * runtime/JSBigInt.cpp:
2969         (JSC::JSBigInt::bitwiseNot):
2970         * runtime/JSBigInt.h:
2971
2972 2019-03-11  Darin Adler  <darin@apple.com>
2973
2974         Specify fixed precision explicitly to prepare to change String::number and StringBuilder::appendNumber floating point behavior
2975         https://bugs.webkit.org/show_bug.cgi?id=195533
2976
2977         Reviewed by Brent Fulgham.
2978
2979         * API/tests/ExecutionTimeLimitTest.cpp:
2980         (testExecutionTimeLimit): Use appendFixedPrecisionNumber.
2981         * runtime/NumberPrototype.cpp:
2982         (JSC::numberProtoFuncToPrecision): Use numberToStringFixedPrecision.
2983         * runtime/Options.cpp:
2984         (JSC::Option::dump const): Use appendFixedPrecisionNumber.
2985
2986 2019-03-10  Ross Kirsling  <ross.kirsling@sony.com>
2987
2988         Invalid flags in a RegExp literal should be an early SyntaxError
2989         https://bugs.webkit.org/show_bug.cgi?id=195514
2990
2991         Reviewed by Darin Adler.
2992
2993         Currently we're throwing a *runtime* SyntaxError; this should occur at parse time. 
2994
2995           12.2.8.1 Static Semantics: Early Errors
2996             PrimaryExpression : RegularExpressionLiteral
2997               - It is a Syntax Error if BodyText of RegularExpressionLiteral cannot be recognized
2998                 using the goal symbol Pattern of the ECMAScript RegExp grammar specified in 21.2.1.
2999               - It is a Syntax Error if FlagText of RegularExpressionLiteral contains any code points
3000                 other than "g", "i", "m",  "s", "u", or "y", or if it contains the same code point more than once.
3001
3002         In fixing this, let's also move flag handling from runtime/ to yarr/.
3003
3004         * yarr/YarrSyntaxChecker.cpp:
3005         (JSC::Yarr::checkSyntax):
3006         Check flags before checking pattern.
3007
3008         * CMakeLists.txt:
3009         * JavaScriptCore.xcodeproj/project.pbxproj:
3010         * Sources.txt:
3011         * bytecompiler/NodesCodegen.cpp:
3012         (JSC::RegExpNode::emitBytecode):
3013         * inspector/ContentSearchUtilities.cpp:
3014         (Inspector::ContentSearchUtilities::findMagicComment):
3015         * runtime/CachedTypes.cpp:
3016         * runtime/RegExp.cpp:
3017         (JSC::RegExp::RegExp):
3018         (JSC::RegExp::createWithoutCaching):
3019         (JSC::RegExp::create):
3020         (JSC::regExpFlags): Deleted.
3021         * runtime/RegExp.h:
3022         * runtime/RegExpCache.cpp:
3023         (JSC::RegExpCache::lookupOrCreate):
3024         (JSC::RegExpCache::ensureEmptyRegExpSlow):
3025         * runtime/RegExpCache.h:
3026         * runtime/RegExpConstructor.cpp:
3027         (JSC::toFlags):
3028         (JSC::regExpCreate):
3029         (JSC::constructRegExp):
3030         * runtime/RegExpKey.h:
3031         (JSC::RegExpKey::RegExpKey):
3032         (WTF::HashTraits<JSC::RegExpKey>::constructDeletedValue):
3033         (WTF::HashTraits<JSC::RegExpKey>::isDeletedValue):
3034         (): Deleted.
3035         * runtime/RegExpPrototype.cpp:
3036         (JSC::regExpProtoFuncCompile):
3037         * testRegExp.cpp:
3038         (parseRegExpLine):
3039         * yarr/RegularExpression.cpp:
3040         (JSC::Yarr::RegularExpression::Private::compile):
3041         * yarr/YarrFlags.cpp: Added.
3042         (JSC::Yarr::parseFlags):
3043         * yarr/YarrFlags.h: Added.
3044         * yarr/YarrInterpreter.h:
3045         (JSC::Yarr::BytecodePattern::ignoreCase const):
3046         (JSC::Yarr::BytecodePattern::multiline const):
3047         (JSC::Yarr::BytecodePattern::sticky const):
3048         (JSC::Yarr::BytecodePattern::unicode const):
3049         (JSC::Yarr::BytecodePattern::dotAll const):
3050         * yarr/YarrPattern.cpp:
3051         (JSC::Yarr::YarrPattern::compile):
3052         (JSC::Yarr::YarrPattern::YarrPattern):
3053         (JSC::Yarr::YarrPattern::dumpPattern):
3054         * yarr/YarrPattern.h:
3055         (JSC::Yarr::YarrPattern::global const):
3056         (JSC::Yarr::YarrPattern::ignoreCase const):
3057         (JSC::Yarr::YarrPattern::multiline const):
3058         (JSC::Yarr::YarrPattern::sticky const):
3059         (JSC::Yarr::YarrPattern::unicode const):
3060         (JSC::Yarr::YarrPattern::dotAll const):
3061         Move flag handling to Yarr and modernize API.
3062
3063 2019-03-09  Robin Morisset  <rmorisset@apple.com>
3064
3065         Compilation can be shrunk by 8 bytes
3066         https://bugs.webkit.org/show_bug.cgi?id=195500
3067
3068         Reviewed by Mark Lam.
3069
3070         * profiler/ProfilerCompilation.cpp:
3071         (JSC::Profiler::Compilation::Compilation):
3072         * profiler/ProfilerCompilation.h:
3073
3074 2019-03-09  Robin Morisset  <rmorisset@apple.com>
3075
3076         BinarySwitch can be shrunk by 8 bytes
3077         https://bugs.webkit.org/show_bug.cgi?id=195493
3078
3079         Reviewed by Mark Lam.
3080
3081         * jit/BinarySwitch.cpp:
3082         (JSC::BinarySwitch::BinarySwitch):
3083         * jit/BinarySwitch.h:
3084
3085 2019-03-09  Robin Morisset  <rmorisset@apple.com>
3086
3087         AsyncStackTrace can be shrunk by 8 bytes
3088         https://bugs.webkit.org/show_bug.cgi?id=195491
3089
3090         Reviewed by Mark Lam.
3091
3092         * inspector/AsyncStackTrace.h:
3093
3094 2019-03-08  Mark Lam  <mark.lam@apple.com>
3095
3096         Stack overflow crash in JSC::JSObject::hasInstance.
3097         https://bugs.webkit.org/show_bug.cgi?id=195458
3098         <rdar://problem/48710195>
3099
3100         Reviewed by Yusuke Suzuki.
3101
3102         * runtime/JSObject.cpp:
3103         (JSC::JSObject::hasInstance):
3104
3105 2019-03-08  Robin Morisset  <rmorisset@apple.com>
3106
3107         IntegerCheckCombiningPhase::Range can be shrunk by 8 bytes
3108         https://bugs.webkit.org/show_bug.cgi?id=195487
3109
3110         Reviewed by Saam Barati.
3111
3112         * dfg/DFGIntegerCheckCombiningPhase.cpp:
3113
3114 2019-03-08  Robin Morisset  <rmorisset@apple.com>
3115
3116         TypeLocation can be shrunk by 8 bytes
3117         https://bugs.webkit.org/show_bug.cgi?id=195483
3118
3119         Reviewed by Mark Lam.
3120
3121         * bytecode/TypeLocation.h:
3122         (JSC::TypeLocation::TypeLocation):
3123
3124 2019-03-08  Robin Morisset  <rmorisset@apple.com>
3125
3126         GetByIdStatus can be shrunk by 16 bytes
3127         https://bugs.webkit.org/show_bug.cgi?id=195480
3128
3129         Reviewed by Saam Barati.
3130
3131         8 bytes from reordering fields
3132         8 more bytes by making the enum State only use 1 byte.
3133
3134         * bytecode/GetByIdStatus.cpp:
3135         (JSC::GetByIdStatus::GetByIdStatus):
3136         * bytecode/GetByIdStatus.h:
3137
3138 2019-03-08  Robin Morisset  <rmorisset@apple.com>
3139
3140         PutByIdVariant can be shrunk by 8 bytes
3141         https://bugs.webkit.org/show_bug.cgi?id=195482
3142
3143         Reviewed by Mark Lam.
3144
3145         * bytecode/PutByIdVariant.h:
3146         (JSC::PutByIdVariant::PutByIdVariant):
3147
3148 2019-03-08  Yusuke Suzuki  <ysuzuki@apple.com>
3149
3150         Unreviewed, follow-up after r242568
3151
3152         Robin pointed that calculation of `numberOfChildren` and `nonEmptyIndex` is unnecessary.
3153
3154         * dfg/DFGAbstractInterpreterInlines.h:
3155         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3156
3157 2019-03-08  Yusuke Suzuki  <ysuzuki@apple.com>
3158
3159         [JSC] We should have more WithoutTransition functions which are usable for JSGlobalObject initialization
3160         https://bugs.webkit.org/show_bug.cgi?id=195447
3161
3162         Reviewed by Filip Pizlo.
3163
3164         This patch reduces # of unnecessary structure transitions in JSGlobalObject initialization to avoid unnecessary allocations
3165         caused by Structure transition. One example is WeakBlock allocation for StructureTransitionTable.
3166         To achieve this, we (1) add putDirectNonIndexAccessorWithoutTransition and putDirectNativeIntrinsicGetterWithoutTransition
3167         to add accessor properties without transition, and (2) add NameAdditionMode::WithoutStructureTransition mode to InternalFunction::finishCreation
3168         to use `putDirectWithoutTransition` instead of `putDirect`.
3169
3170         * inspector/JSInjectedScriptHostPrototype.cpp:
3171         (Inspector::JSInjectedScriptHostPrototype::finishCreation):
3172         * inspector/JSJavaScriptCallFramePrototype.cpp:
3173         (Inspector::JSJavaScriptCallFramePrototype::finishCreation):
3174         * runtime/ArrayConstructor.cpp:
3175         (JSC::ArrayConstructor::finishCreation):
3176         * runtime/AsyncFunctionConstructor.cpp:
3177         (JSC::AsyncFunctionConstructor::finishCreation):
3178         * runtime/AsyncGeneratorFunctionConstructor.cpp:
3179         (JSC::AsyncGeneratorFunctionConstructor::finishCreation):
3180         * runtime/BigIntConstructor.cpp:
3181         (JSC::BigIntConstructor::finishCreation):
3182         * runtime/BooleanConstructor.cpp:
3183         (JSC::BooleanConstructor::finishCreation):
3184         * runtime/DateConstructor.cpp:
3185         (JSC::DateConstructor::finishCreation):
3186         * runtime/ErrorConstructor.cpp:
3187         (JSC::ErrorConstructor::finishCreation):
3188         * runtime/FunctionConstructor.cpp:
3189         (JSC::FunctionConstructor::finishCreation):
3190         * runtime/FunctionPrototype.cpp:
3191         (JSC::FunctionPrototype::finishCreation):
3192         (JSC::FunctionPrototype::addFunctionProperties):
3193         (JSC::FunctionPrototype::initRestrictedProperties):
3194         * runtime/FunctionPrototype.h:
3195         * runtime/GeneratorFunctionConstructor.cpp:
3196         (JSC::GeneratorFunctionConstructor::finishCreation):
3197         * runtime/InternalFunction.cpp:
3198         (JSC::InternalFunction::finishCreation):
3199         * runtime/InternalFunction.h:
3200         * runtime/IntlCollatorConstructor.cpp:
3201         (JSC::IntlCollatorConstructor::finishCreation):
3202         * runtime/IntlDateTimeFormatConstructor.cpp:
3203         (JSC::IntlDateTimeFormatConstructor::finishCreation):
3204         * runtime/IntlNumberFormatConstructor.cpp:
3205         (JSC::IntlNumberFormatConstructor::finishCreation):
3206         * runtime/IntlPluralRulesConstructor.cpp:
3207         (JSC::IntlPluralRulesConstructor::finishCreation):
3208         * runtime/JSArrayBufferConstructor.cpp:
3209         (JSC::JSGenericArrayBufferConstructor<sharingMode>::finishCreation):
3210         * runtime/JSArrayBufferPrototype.cpp:
3211         (JSC::JSArrayBufferPrototype::finishCreation):
3212         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
3213         (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::finishCreation):
3214         * runtime/JSGlobalObject.cpp:
3215         (JSC::JSGlobalObject::init):
3216         * runtime/JSObject.cpp:
3217         (JSC::JSObject::putDirectNonIndexAccessorWithoutTransition):
3218         (JSC::JSObject::putDirectNativeIntrinsicGetterWithoutTransition):
3219         * runtime/JSObject.h:
3220         * runtime/JSPromiseConstructor.cpp:
3221         (JSC::JSPromiseConstructor::finishCreation):
3222         * runtime/JSTypedArrayViewConstructor.cpp:
3223         (JSC::JSTypedArrayViewConstructor::finishCreation):
3224         * runtime/JSTypedArrayViewPrototype.cpp:
3225         (JSC::JSTypedArrayViewPrototype::finishCreation):
3226         * runtime/MapConstructor.cpp:
3227         (JSC::MapConstructor::finishCreation):
3228         * runtime/MapPrototype.cpp:
3229         (JSC::MapPrototype::finishCreation):
3230         * runtime/NativeErrorConstructor.cpp:
3231         (JSC::NativeErrorConstructorBase::finishCreation):
3232         * runtime/NullGetterFunction.h:
3233         * runtime/NullSetterFunction.h:
3234         * runtime/NumberConstructor.cpp:
3235         (JSC::NumberConstructor::finishCreation):
3236         * runtime/ObjectConstructor.cpp:
3237         (JSC::ObjectConstructor::finishCreation):
3238         * runtime/ProxyConstructor.cpp:
3239         (JSC::ProxyConstructor::finishCreation):
3240         * runtime/RegExpConstructor.cpp:
3241         (JSC::RegExpConstructor::finishCreation):
3242         * runtime/RegExpPrototype.cpp:
3243         (JSC::RegExpPrototype::finishCreation):
3244         * runtime/SetConstructor.cpp:
3245         (JSC::SetConstructor::finishCreation):
3246         * runtime/SetPrototype.cpp:
3247         (JSC::SetPrototype::finishCreation):
3248         * runtime/StringConstructor.cpp:
3249         (JSC::StringConstructor::finishCreation):
3250         * runtime/SymbolConstructor.cpp:
3251         (JSC::SymbolConstructor::finishCreation):
3252         * runtime/WeakMapConstructor.cpp:
3253         (JSC::WeakMapConstructor::finishCreation):
3254         * runtime/WeakSetConstructor.cpp:
3255         (JSC::WeakSetConstructor::finishCreation):
3256         * wasm/js/WebAssemblyCompileErrorConstructor.cpp:
3257         (JSC::WebAssemblyCompileErrorConstructor::finishCreation):
3258         * wasm/js/WebAssemblyInstanceConstructor.cpp:
3259         (JSC::WebAssemblyInstanceConstructor::finishCreation):
3260         * wasm/js/WebAssemblyLinkErrorConstructor.cpp:
3261         (JSC::WebAssemblyLinkErrorConstructor::finishCreation):
3262         * wasm/js/WebAssemblyMemoryConstructor.cpp:
3263         (JSC::WebAssemblyMemoryConstructor::finishCreation):
3264         * wasm/js/WebAssemblyModuleConstructor.cpp:
3265         (JSC::WebAssemblyModuleConstructor::finishCreation):
3266         * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
3267         (JSC::WebAssemblyRuntimeErrorConstructor::finishCreation):
3268         * wasm/js/WebAssemblyTableConstructor.cpp:
3269         (JSC::WebAssemblyTableConstructor::finishCreation):
3270
3271 2019-03-08  Tadeu Zagallo  <tzagallo@apple.com>
3272
3273         op_check_tdz does not def its argument
3274         https://bugs.webkit.org/show_bug.cgi?id=192880
3275         <rdar://problem/46221598>
3276
3277         Reviewed by Saam Barati.
3278
3279         This prevented the for-in loop optimization in the bytecode generator, since
3280         the analysis sees a redefinition of the loop variable.
3281
3282         * bytecode/BytecodeUseDef.h:
3283         (JSC::computeDefsForBytecodeOffset):
3284
3285 2019-03-07  Yusuke Suzuki  <ysuzuki@apple.com>
3286
3287         [JSC] Make more fields lazy in JSGlobalObject
3288         https://bugs.webkit.org/show_bug.cgi?id=195449
3289
3290         Reviewed by Mark Lam.
3291
3292         This patch makes more fields lazy-allocated in JSGlobalObject to save memory.
3293
3294         1. Some minor structures like moduleRecordStructure.
3295         2. Some functions like parseInt / parseFloat. While they are eagerly created in JIT mode anyway to materialize NumberConstructor, we can lazily allocate them in non JIT mode.
3296         3. ArrayBuffer constructor. While it is eagerly allocated in WebCore, we can make lazily allocated in JSC.
3297
3298         * interpreter/Interpreter.cpp:
3299         (JSC::Interpreter::execute):
3300         * runtime/JSArrayBufferPrototype.h:
3301         * runtime/JSGlobalObject.cpp:
3302         (JSC::JSGlobalObject::init):
3303         (JSC::JSGlobalObject::visitChildren):
3304         * runtime/JSGlobalObject.h:
3305         (JSC::JSGlobalObject::parseIntFunction const):
3306         (JSC::JSGlobalObject::parseFloatFunction const):
3307         (JSC::JSGlobalObject::evalFunction const):
3308         (JSC::JSGlobalObject::strictEvalActivationStructure const):
3309         (JSC::JSGlobalObject::moduleRecordStructure const):
3310         (JSC::JSGlobalObject::moduleNamespaceObjectStructure const):
3311         (JSC::JSGlobalObject::proxyObjectStructure const):
3312         (JSC::JSGlobalObject::callableProxyObjectStructure const):
3313         (JSC::JSGlobalObject::proxyRevokeStructure const):
3314         (JSC::JSGlobalObject::arrayBufferConstructor const):
3315         (JSC::JSGlobalObject::arrayBufferPrototype const):
3316         (JSC::JSGlobalObject::arrayBufferStructure const):
3317         * runtime/ProxyObject.h:
3318         * runtime/StrictEvalActivation.cpp:
3319         (JSC::StrictEvalActivation::StrictEvalActivation):
3320         * runtime/StrictEvalActivation.h:
3321         * wasm/js/JSWebAssemblyMemory.cpp:
3322         (JSC::JSWebAssemblyMemory::buffer):
3323         * wasm/js/WebAssemblyModuleConstructor.cpp:
3324         (JSC::webAssemblyModuleCustomSections):
3325
3326 2019-03-07  Yusuke Suzuki  <ysuzuki@apple.com>
3327
3328         [JSC] Remove merging must handle values into proven types in CFA
3329         https://bugs.webkit.org/show_bug.cgi?id=195444
3330
3331         Reviewed by Saam Barati.
3332
3333         Previously, we are merging must handle values as a proven constant in CFA. This is OK as long as this proven AbstractValue is blurred by merging the other legit AbstractValues
3334         from the successors. But let's consider the following code, this is actually generated DFG graph from the attached test in r242626.
3335
3336             Block #2 (loop header) succ #3, #4
3337             ...
3338             1: ForceOSRExit
3339             ...
3340             2: JSConstant(0)
3341             3: SetLocal(@2, loc6)
3342             ...
3343             4: Branch(#3, #4)
3344
3345             Block #3 (This is OSR entry target) pred #2, #3, must handle value for loc6 => JSConstant(Int32, 31)
3346             ...
3347             5: GetLocal(loc6)
3348             6: StringFromCharCode(@5)
3349             ...
3350
3351         Block #3 is OSR entry target. So we have must handle value for loc6 and it is Int32 constant 31. Then we merge this constant as a proven value in #3's loc6 AbstractValue.
3352         If the value from #2 blurs the value, it is OK. However, #2 has ForceOSRExit. So must handle value suddenly becomes the only source of loc6 in #3. Then we use this constant
3353         as a proven value. But this is not expected behavior since must handle value is just a snapshot of the locals when we kick off the concurrent compilation. In the above example,
3354         we assume that loop index is an constant 31, but it is wrong, and OSR entry fails. Because there is no strong assumption that the must handle value is the proven type or value,
3355         we should not merge it in CFA.
3356
3357         Since (1) this is just an optimization, (2) type information is already propagated in prediction injection phase, and (3) the must handle value does not show the performance
3358         progression in r211461 and we no longer see type misprediction in marsaglia-osr-entry.js, this patch simply removes must handle value type widening in CFA.
3359
3360         * dfg/DFGCFAPhase.cpp:
3361         (JSC::DFG::CFAPhase::run):
3362         (JSC::DFG::CFAPhase::performBlockCFA):
3363         (JSC::DFG::CFAPhase::injectOSR): Deleted.
3364
3365 2019-03-07  Yusuke Suzuki  <ysuzuki@apple.com>
3366
3367         [JSC] StringFromCharCode fast path should accept 0xff in DFG and FTL
3368         https://bugs.webkit.org/show_bug.cgi?id=195429
3369
3370         Reviewed by Saam Barati.
3371
3372         We can create single characters without allocation up to 0xff character code. But currently, DFGSpeculativeJIT and FTLLowerDFGToB3 go to the slow path
3373         for 0xff case. On the other hand, DFG DoesGC phase says GC won't happen if the child is int32 constant and it is <= 0xff. So, if you have `String.fromCharCode(0xff)`,
3374         this breaks the assumption in DFG DoesGC. The correct fix is changing the check in DFGSpeculativeJIT and FTLLowerDFGToB3 from AboveOrEqual to Above.
3375         Note that ThunkGenerators's StringFromCharCode thunk was correct.
3376
3377         * dfg/DFGSpeculativeJIT.cpp:
3378         (JSC::DFG::SpeculativeJIT::compileFromCharCode):
3379         * ftl/FTLLowerDFGToB3.cpp:
3380         (JSC::FTL::DFG::LowerDFGToB3::compileStringFromCharCode):
3381
3382 2019-03-07  Mark Lam  <mark.lam@apple.com>
3383
3384         Follow up refactoring in try-finally code after r242591.
3385         https://bugs.webkit.org/show_bug.cgi?id=195428
3386
3387         Reviewed by Saam Barati.
3388
3389         1. Added some comments in emitFinallyCompletion() to describe each completion case.
3390         2. Converted CatchEntry into a struct.
3391         3. Renamed variable hasBreaksOrContinuesNotCoveredByJumps to hasBreaksOrContinuesThatEscapeCurrentFinally
3392            to be more clear about its purpose.
3393
3394         * bytecompiler/BytecodeGenerator.cpp:
3395         (JSC::BytecodeGenerator::generate):
3396         (JSC::BytecodeGenerator::emitOutOfLineExceptionHandler):
3397         (JSC::BytecodeGenerator::emitFinallyCompletion):
3398         * bytecompiler/BytecodeGenerator.h:
3399
3400 2019-03-07  Saam Barati  <sbarati@apple.com>
3401
3402         CompactVariableMap::Handle's copy operator= leaks the previous data
3403         https://bugs.webkit.org/show_bug.cgi?id=195398
3404
3405         Reviewed by Yusuke Suzuki.
3406
3407         The copy constructor was just assigning |this| to the new value,
3408         forgetting to decrement the ref count of the thing pointed to by
3409         the |this| handle. Based on Yusuke's suggestion, this patch refactors
3410         the move constructor, move operator=, and copy operator= to use the
3411         swap() primitive and the copy constructor primitive.
3412
3413         * parser/VariableEnvironment.cpp:
3414         (JSC::CompactVariableMap::Handle::Handle):
3415         (JSC::CompactVariableMap::Handle::swap):
3416         (JSC::CompactVariableMap::Handle::operator=): Deleted.
3417         * parser/VariableEnvironment.h:
3418         (JSC::CompactVariableMap::Handle::Handle):
3419         (JSC::CompactVariableMap::Handle::operator=):
3420
3421 2019-03-07  Tadeu Zagallo  <tzagallo@apple.com>
3422
3423         Lazily decode cached bytecode
3424         https://bugs.webkit.org/show_bug.cgi?id=194810
3425
3426         Reviewed by Saam Barati.
3427
3428         Like lazy parsing, we should pause at code block boundaries. Instead
3429         of always eagerly decoding UnlinkedFunctionExecutable's UnlinkedCodeBlocks,
3430         we store their offsets in the executable and lazily decode them on the next
3431         call to `unlinkedCodeBlockFor`.
3432
3433         * bytecode/UnlinkedFunctionExecutable.cpp:
3434         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
3435         (JSC::UnlinkedFunctionExecutable::~UnlinkedFunctionExecutable):
3436         (JSC::UnlinkedFunctionExecutable::visitChildren):
3437         (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
3438         (JSC::UnlinkedFunctionExecutable::decodeCachedCodeBlocks):
3439         * bytecode/UnlinkedFunctionExecutable.h:
3440         * runtime/CachedTypes.cpp:
3441         (JSC::Decoder::Decoder):
3442         (JSC::Decoder::~Decoder):
3443         (JSC::Decoder::create):
3444         (JSC::Decoder::offsetOf):
3445         (JSC::Decoder::cacheOffset):
3446         (JSC::Decoder::ptrForOffsetFromBase):
3447         (JSC::Decoder::handleForEnvironment const):
3448         (JSC::Decoder::setHandleForEnvironment):
3449         (JSC::Decoder::addFinalizer):
3450         (JSC::VariableLengthObject::isEmpty const):
3451         (JSC::CachedWriteBarrier::isEmpty const):
3452         (JSC::CachedFunctionExecutable::unlinkedCodeBlockForCall const):
3453         (JSC::CachedFunctionExecutable::unlinkedCodeBlockForConstruct const):
3454         (JSC::CachedFunctionExecutable::decode const):
3455         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
3456         (JSC::decodeCodeBlockImpl):
3457         (JSC::isCachedBytecodeStillValid):
3458         (JSC::decodeFunctionCodeBlock):
3459         * runtime/CachedTypes.h:
3460         (JSC::Decoder::vm):
3461
3462 2019-03-06  Mark Lam  <mark.lam@apple.com>
3463
3464         Exception is a JSCell, not a JSObject.
3465         https://bugs.webkit.org/show_bug.cgi?id=195392
3466
3467         Reviewed by Saam Barati.
3468
3469         Exception is a VM implementation construct to carry a stack trace for the point
3470         where it is thrown from.  As a reminder, an Exception is needed because:
3471         1. JS code can throw primitives as well that are non-cells.
3472         2. Error objects capture the stack trace at the point where they are constructed,
3473            which is not always the same as the point where they are thrown (if they are
3474            thrown).
3475
3476         Hence, Exception should not be visible to JS code, and therefore should not be a
3477         JSObject.  Hence, it should not inherit from JSDestructibleObject.
3478
3479         This patch changes the following:
3480
3481         1. Exception now inherits directly from JSCell instead.
3482
3483         2. Places where we return an Exception masquerading as a JSObject* are now
3484            updated to return a nullptr when we encounter an exception.
3485
3486         3. We still return Exception* as JSValue or EncodedJSValue when we encounter an
3487            exception in functions that return JSValue or EncodedJSValue.  This is because
3488            the number that implements the following pattern is too numerous:
3489
3490                 return throw<Some Error>(...)
3491
3492            We'll leave these as is for now.
3493
3494         * bytecode/CodeBlock.h:
3495         (JSC::ScriptExecutable::prepareForExecution):
3496         * interpreter/Interpreter.cpp:
3497         (JSC::Interpreter::executeProgram):
3498         (JSC::Interpreter::executeCall):
3499         (JSC::Interpreter::executeConstruct):
3500         (JSC::Interpreter::prepareForRepeatCall):
3501         (JSC::Interpreter::execute):
3502         (JSC::Interpreter::executeModuleProgram):
3503         * jit/JITOperations.cpp:
3504         * llint/LLIntSlowPaths.cpp:
3505         (JSC::LLInt::setUpCall):
3506         * runtime/ConstructData.cpp:
3507         (JSC::construct):
3508         * runtime/Error.cpp:
3509         (JSC::throwConstructorCannotBeCalledAsFunctionTypeError):
3510         (JSC::throwTypeError):
3511         (JSC::throwSyntaxError):
3512         * runtime/Error.h:
3513         (JSC::throwRangeError):
3514         * runtime/Exception.cpp:
3515         (JSC::Exception::createStructure):
3516         * runtime/Exception.h:
3517         * runtime/ExceptionHelpers.cpp:
3518         (JSC::throwOutOfMemoryError):
3519         (JSC::throwStackOverflowError):
3520         (JSC::throwTerminatedExecutionException):
3521         * runtime/ExceptionHelpers.h:
3522         * runtime/FunctionConstructor.cpp:
3523         (JSC::constructFunction):
3524         (JSC::constructFunctionSkippingEvalEnabledCheck):
3525         * runtime/IntlPluralRules.cpp:
3526         (JSC::IntlPluralRules::resolvedOptions):
3527         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
3528         (JSC::constructGenericTypedArrayViewWithArguments):
3529         * runtime/JSObject.h:
3530         * runtime/ObjectConstructor.cpp:
3531         (JSC::objectConstructorSeal):
3532         (JSC::objectConstructorFreeze):
3533         * runtime/ProgramExecutable.cpp:
3534         (JSC::ProgramExecutable::initializeGlobalProperties):
3535         * runtime/RegExpConstructor.cpp:
3536         (JSC::regExpCreate):
3537         (JSC::constructRegExp):
3538         * runtime/ScriptExecutable.cpp:
3539         (JSC::ScriptExecutable::newCodeBlockFor):
3540         (JSC::ScriptExecutable::prepareForExecutionImpl):
3541         * runtime/ScriptExecutable.h:
3542         * runtime/ThrowScope.cpp:
3543         (JSC::ThrowScope::throwException):
3544         * runtime/ThrowScope.h:
3545         (JSC::ThrowScope::throwException):
3546         (JSC::throwException):
3547         * runtime/VM.cpp:
3548         (JSC::VM::throwException):
3549         * runtime/VM.h:
3550
3551 2019-03-06  Ross Kirsling  <ross.kirsling@sony.com>
3552
3553         [Win] Remove -DUCHAR_TYPE=wchar_t stopgap and learn to live with char16_t.
3554         https://bugs.webkit.org/show_bug.cgi?id=195346
3555
3556         Reviewed by Fujii Hironori.
3557
3558         * jsc.cpp:
3559         (currentWorkingDirectory):
3560         (fetchModuleFromLocalFileSystem):
3561         * runtime/DateConversion.cpp:
3562         (JSC::formatDateTime):
3563         Use wchar helpers as needed.
3564
3565 2019-03-06  Mark Lam  <mark.lam@apple.com>
3566
3567         Fix incorrect handling of try-finally completion values.
3568         https://bugs.webkit.org/show_bug.cgi?id=195131
3569         <rdar://problem/46222079>
3570
3571         Reviewed by Saam Barati and Yusuke Suzuki.
3572
3573         Consider the following:
3574
3575             function foo() {                        // line 1
3576                 try {
3577                     return 42;                      // line 3
3578                 } finally {
3579                     for (var j = 0; j < 1; j++) {   // line 5
3580                         try {
3581                             throw '';               // line 7
3582                         } finally {
3583                             continue;               // line 9
3584                         }
3585                     }
3586                 }                                   // line 11
3587             }
3588             var result = foo();
3589
3590         With the current (before fix) code base, result will be the exception object thrown
3591         at line 7.  The expected result should be 42, returned at line 3.
3592
3593         The bug is that we were previously only using one set of completion type and
3594         value registers for the entire function.  This is inadequate because the outer
3595         try-finally needs to preserve its own completion type and value ({ Return, 42 }
3596         in this case) in order to be able to complete correctly.
3597
3598         One might be deceived into thinking that the above example should complete with
3599         the exception thrown at line 7.  However, according to Section 13.15.8 of the
3600         ECMAScript spec, the 'continue' in the finally at line 9 counts as an abrupt
3601         completion.  As a result, it overrides the throw from line 7.  After the continue,
3602         execution resumes at the top of the loop at line 5, followed by a normal completion
3603         at line 11.
3604
3605         Also according to Section 13.15.8, given that the completion type of the outer
3606         finally is normal, the resultant completion of the outer try-finally should be
3607         the completion of the outer try block i.e. { Return, 42 }.
3608
3609         This patch makes the following changes:
3610         
3611         1. Fix handling of finally completion to use a unique set of completion
3612            type and value registers for each FinallyContext.
3613
3614         2. Move the setting of Throw completion type to the out of line exception handler.
3615            This makes the mainline code slightly less branchy.
3616
3617         3. Introduce emitOutOfLineCatchHandler(), emitOutOfLineFinallyHandler(), and
3618            emitOutOfLineExceptionHandler() to make it clearer that these are not emitting
3619            bytecode inline.  Also, these make it clearer when we're emitting a handler
3620            for a catch vs a finally.
3621
3622         4. Allocate the FinallyContext on the stack instead of as a member of the
3623            heap allocated ControlFlowScope.  This simplifies its life-cycle management
3624            and reduces the amount of needed copying.
3625
3626         5. Update emitFinallyCompletion() to propagate the completion type and value to
3627            the outer FinallyContext when needed.
3628
3629         6. Fix emitJumpIf() to use the right order of operands.  Previously, we were
3630            only using it to do op_stricteq and op_nstricteq comparisons.  So, the order
3631            wasn't important.  We now use it to also do op_beloweq comparisons.  Hence,
3632            the order needs to be corrected.
3633
3634         7. Remove the unused CompletionType::Break and Continue.  These are encoded with
3635            the jumpIDs of the jump targets instead.
3636
3637         Relevant specifications:
3638         Section 13.15.8: https://www.ecma-international.org/ecma-262/9.0/index.html#sec-try-statement-runtime-semantics-evaluation
3639         Section 6.3.2.4: https://www.ecma-international.org/ecma-262/9.0/index.html#sec-updateempty
3640
3641         * bytecompiler/BytecodeGenerator.cpp:
3642         (JSC::FinallyContext::FinallyContext):
3643         (JSC::BytecodeGenerator::generate):
3644         (JSC::BytecodeGenerator::BytecodeGenerator):
3645         (JSC::BytecodeGenerator::pushFinallyControlFlowScope):
3646         (JSC::BytecodeGenerator::popFinallyControlFlowScope):
3647         (JSC::BytecodeGenerator::emitOutOfLineCatchHandler):
3648         (JSC::BytecodeGenerator::emitOutOfLineFinallyHandler):
3649         (JSC::BytecodeGenerator::emitOutOfLineExceptionHandler):
3650         (JSC::BytecodeGenerator::emitEnumeration):
3651         (JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded):
3652         (JSC::BytecodeGenerator::emitReturnViaFinallyIfNeeded):
3653         (JSC::BytecodeGenerator::emitFinallyCompletion):
3654         (JSC::BytecodeGenerator::emitJumpIf):
3655         (JSC::BytecodeGenerator::emitCatch): Deleted.
3656         (JSC::BytecodeGenerator::allocateCompletionRecordRegisters): Deleted.
3657         (JSC::BytecodeGenerator::releaseCompletionRecordRegisters): Deleted.
3658         * bytecompiler/BytecodeGenerator.h:
3659         (JSC::FinallyContext::completionTypeRegister const):
3660         (JSC::FinallyContext::completionValueRegister const):
3661         (JSC::ControlFlowScope::ControlFlowScope):
3662         (JSC::BytecodeGenerator::emitLoad):
3663         (JSC::BytecodeGenerator::CompletionRecordScope::CompletionRecordScope): Deleted.
3664         (JSC::BytecodeGenerator::CompletionRecordScope::~CompletionRecordScope): Deleted.
3665         (JSC::BytecodeGenerator::completionTypeRegister const): Deleted.
3666         (JSC::BytecodeGenerator::completionValueRegister const): Deleted.
3667         (JSC::BytecodeGenerator::emitSetCompletionType): Deleted.
3668         (JSC::BytecodeGenerator::emitSetCompletionValue): Deleted.
3669         * bytecompiler/NodesCodegen.cpp:
3670         (JSC::TryNode::emitBytecode):
3671
3672 2019-03-06  Saam Barati  <sbarati@apple.com>
3673
3674         JSScript should keep the cache file locked for the duration of its existence and should truncate the cache when it is out of date
3675         https://bugs.webkit.org/show_bug.cgi?id=195186
3676
3677         Reviewed by Keith Miller.
3678
3679         This patch makes it so that JSScript will keep its bytecode cache file
3680         locked as long as the JSScript is alive. This makes it obvious that it's
3681         safe to update that file, as it will only be used in a single VM, across
3682         all processes, at a single time. We may be able to extend this in the future
3683         if we can atomically update it across VMs/processes. However, we're choosing
3684         more restricted semantics now as it's always easier to extend these semantics
3685         in the future opposed to having to support the more flexible behavior
3686         up front.
3687         
3688         This patch also:
3689         - Adds error messages if writing the cache fails. We don't expect this to
3690           fail, but previously we would say we cached it even if write() fails.
3691         - Removes the unused m_moduleKey field.
3692         - Makes calling cacheBytecodeWithError with an already non-empty cache file fail.
3693           In the future, we should extend this to just fill in the parts of the cache
3694           that are not present. But we don't have the ability to do that yet, so we
3695           just result in an error for now.
3696
3697         * API/JSScript.mm:
3698         (-[JSScript dealloc]):
3699         (-[JSScript readCache]):
3700         (-[JSScript init]):
3701         (-[JSScript writeCache:]):
3702         * API/JSScriptInternal.h:
3703         * API/tests/testapi.mm:
3704         (testCacheFileIsExclusive):
3705         (testCacheFileFailsWhenItsAlreadyCached):
3706         (testObjectiveCAPI):
3707
3708 2019-03-06  Christopher Reid  <chris.reid@sony.com>
3709
3710         Followups to (r242306): Use LockHolder instead of std::lock_guard on Remote Inspector Locks
3711         https://bugs.webkit.org/show_bug.cgi?id=195381
3712
3713         Reviewed by Mark Lam.
3714
3715         Replacing std::lock_guard uses in Remote Inspector with WTF::LockHolder.
3716         Also using `= { }` for struct initialization instead of memeset.
3717
3718         * inspector/remote/RemoteConnectionToTarget.cpp:
3719         * inspector/remote/RemoteInspector.cpp:
3720         * inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm:
3721         * inspector/remote/cocoa/RemoteInspectorCocoa.mm:
3722         * inspector/remote/cocoa/RemoteInspectorXPCConnection.mm:
3723         * inspector/remote/glib/RemoteInspectorGlib.cpp:
3724         * inspector/remote/playstation/RemoteInspectorPlayStation.cpp:
3725         * inspector/remote/playstation/RemoteInspectorSocketClientPlayStation.cpp:
3726         * inspector/remote/playstation/RemoteInspectorSocketPlayStation.cpp:
3727         * inspector/remote/playstation/RemoteInspectorSocketServerPlayStation.cpp:
3728
3729 2019-03-06  Saam Barati  <sbarati@apple.com>
3730
3731         Air::reportUsedRegisters must padInterference
3732         https://bugs.webkit.org/show_bug.cgi?id=195303
3733         <rdar://problem/48270343>
3734
3735         Reviewed by Keith Miller.
3736
3737         reportUsedRegisters uses reg liveness to eliminate loads/moves into dead
3738         registers. However, liveness can report incorrect results in certain 
3739         scenarios when considering liveness at instruction boundaries. For example,
3740         it can go wrong when an Inst has a LateUse of a register and the following
3741         Inst has an EarlyDef of that same register. Such a scenario could lead us
3742         to incorrectly say the register is not live-in to the first Inst. Pad
3743         interference inserts Nops between such instruction boundaries that cause
3744         this issue.
3745         
3746         The test with this patch fixes the issue in reportUsedRegisters. This patch
3747         also conservatively makes it so that lowerAfterRegAlloc calls padInterference
3748         since it also reasons about liveness.
3749
3750         * b3/air/AirLowerAfterRegAlloc.cpp:
3751         (JSC::B3::Air::lowerAfterRegAlloc):
3752         * b3/air/AirPadInterference.h:
3753         * b3/air/AirReportUsedRegisters.cpp:
3754         (JSC::B3::Air::reportUsedRegisters):
3755         * b3/testb3.cpp:
3756         (JSC::B3::testReportUsedRegistersLateUseNotDead):
3757         (JSC::B3::run):
3758
3759 2019-03-06  Yusuke Suzuki  <ysuzuki@apple.com>
3760
3761         [JSC] AI should not propagate AbstractValue relying on constant folding phase
3762         https://bugs.webkit.org/show_bug.cgi?id=195375
3763
3764         Reviewed by Saam Barati.
3765
3766         MakeRope rule in AI attempts to propagate the node, which will be produced after constant folding phase runs.
3767         This is wrong since we do not guarantee that constant folding phase runs after AI runs (e.g. DFGSpeculativeJIT
3768         and FTLLowerDFGToB3 run AI). This results in the bug that the value produced at runtime is different from the
3769         proven constant value in AI. In the attached test, AI says the value is SpecStringIdent while the resulted value
3770         at runtime is SpecStringVar, resulting in wrong MakeRope code. This patch removes the path propagating the node
3771         relying on constant folding phase.
3772
3773         * dfg/DFGAbstractInterpreterInlines.h:
3774         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3775
3776 2019-03-05  Saam barati  <sbarati@apple.com>
3777
3778         op_switch_char broken for rope strings after JSRopeString layout rewrite
3779         https://bugs.webkit.org/show_bug.cgi?id=195339
3780         <rdar://problem/48592545>
3781
3782         Reviewed by Yusuke Suzuki.
3783
3784         When we did the JSString rewrite, we accidentally broke LLInt's switch_char
3785         for rope strings. That change made it so that we always go to the slow path
3786         for ropes. That's wrong. The slow path should only be taken when the rope
3787         is of length 1. For lengths other than 1, we need to fall through to the
3788         default case. This patch fixes this.
3789
3790         * llint/LowLevelInterpreter32_64.asm:
3791         * llint/LowLevelInterpreter64.asm:
3792         * runtime/JSString.h:
3793
3794 2019-03-05  Yusuke Suzuki  <ysuzuki@apple.com>
3795
3796         [JSC] Should check exception for JSString::toExistingAtomicString
3797         https://bugs.webkit.org/show_bug.cgi?id=195337
3798
3799         Reviewed by Keith Miller, Saam Barati, and Mark Lam.
3800
3801         We missed the exception check for JSString::toExistingAtomicString while it can resolve
3802         a rope and throw an OOM exception. This patch adds necessary exception checks. This patch
3803         fixes test failures in debug build, reported in https://bugs.webkit.org/show_bug.cgi?id=194375#c93.
3804
3805         * dfg/DFGOperations.cpp:
3806         * jit/JITOperations.cpp:
3807         (JSC::getByVal):
3808         * llint/LLIntSlowPaths.cpp:
3809         (JSC::LLInt::getByVal):
3810         * runtime/CommonSlowPaths.cpp:
3811         (JSC::SLOW_PATH_DECL):
3812
3813 2019-03-04  Yusuke Suzuki  <ysuzuki@apple.com>
3814
3815         Unreviewed, build fix for debug builds after r242397
3816
3817         * runtime/JSString.h:
3818
3819 2019-03-04  Yusuke Suzuki  <ysuzuki@apple.com>
3820
3821         [JSC] Store bits for JSRopeString in 3 stores
3822         https://bugs.webkit.org/show_bug.cgi?id=195234
3823
3824         Reviewed by Saam Barati.
3825
3826         This patch cleans up the initialization of JSRopeString fields in DFG and FTL.
3827         Previously, we store some part of data separately. Instead, this patch calculates
3828         the data first by bit operations and store calculated data with fewer stores.
3829
3830         This patch also cleans up is8Bit and isSubstring flags. We put them in lower bits
3831         of the first fiber instead of the upper 16 bits. Since we only have 3 bit flags, (isRope, is8Bit, isSubstring),
3832         we can put them into the lower 3 bits, they are always empty due to alignment.
3833
3834         * bytecode/AccessCase.cpp:
3835         (JSC::AccessCase::generateImpl): A bit clean up of StringLength IC to give a chance of unnecessary mov removal.
3836         * dfg/DFGSpeculativeJIT.cpp:
3837         (JSC::DFG::SpeculativeJIT::canBeRope):
3838         (JSC::DFG::SpeculativeJIT::compileGetArrayLength):
3839         (JSC::DFG::SpeculativeJIT::compileMakeRope):
3840         * dfg/DFGSpeculativeJIT.h:
3841         * ftl/FTLAbstractHeapRepository.cpp:
3842         (JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
3843         * ftl/FTLAbstractHeapRepository.h:
3844         * ftl/FTLLowerDFGToB3.cpp:
3845         (JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
3846         (JSC::FTL::DFG::LowerDFGToB3::isRopeString):
3847         (JSC::FTL::DFG::LowerDFGToB3::isNotRopeString):
3848         * runtime/JSString.cpp:
3849         (JSC::JSString::visitChildren):
3850         * runtime/JSString.h:
3851         (JSC::JSString::is8Bit const):
3852         (JSC::JSString::isSubstring const):
3853         * tools/JSDollarVM.cpp:
3854         (JSC::functionCreateNullRopeString):
3855         (JSC::JSDollarVM::finishCreation):
3856
3857 2019-03-04  Joseph Pecoraro  <pecoraro@apple.com>
3858
3859         ITMLKit Inspector: Data Bindings / Associated Data for nodes
3860         https://bugs.webkit.org/show_bug.cgi?id=195290
3861         <rdar://problem/48304019>
3862
3863         Reviewed by Devin Rousso.
3864
3865         * inspector/protocol/DOM.json:
3866
3867 2019-03-04  Yusuke Suzuki  <ysuzuki@apple.com>
3868
3869         [JSC] Make Reflect lazily-allocated by dropping @Reflect references from builtin JS