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