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