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