521baaaa39e8ed45945f2be0f4398681e8473d70
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2019-06-04  Yusuke Suzuki  <ysuzuki@apple.com>
2
3         Unreviewed, update exception scope for putByIndexBeyondVectorLength
4         https://bugs.webkit.org/show_bug.cgi?id=198477
5
6         * runtime/JSObject.cpp:
7         (JSC::JSObject::putByIndexBeyondVectorLength):
8
9 2019-06-04  Tadeu Zagallo  <tzagallo@apple.com>
10
11         Argument elimination should check transitive dependents for interference
12         https://bugs.webkit.org/show_bug.cgi?id=198520
13         <rdar://problem/50863343>
14
15         Reviewed by Filip Pizlo.
16
17         Consider the following program:
18
19             a: CreateRest
20             -->
21                 b: CreateRest
22             <--
23             c: Spread(@a)
24             d: Spread(@b)
25             e: NewArrayWithSpread(@a, @b)
26             f: KillStack(locX)
27             g: LoadVarargs(@e)
28
29         Suppose @b reads locX, then we cannot transform @e to PhantomNewArraySpread, since that would
30         move the stack access from @b into @g, and that stack location is no longer valid at that point.
31
32         We fix that by computing a set of all inline call frames that any argument elimination candidate
33         depends on and checking each of them for interference in `eliminateCandidatesThatInterfere`.
34
35         * dfg/DFGArgumentsEliminationPhase.cpp:
36
37 2019-06-04  Yusuke Suzuki  <ysuzuki@apple.com>
38
39         [JSC] InferredValue should not be a JSCell
40         https://bugs.webkit.org/show_bug.cgi?id=198407
41
42         Reviewed by Filip Pizlo.
43
44         Allocating InferredValue as a JSCell is too costly in terms of memory. Gmail has 90000 FunctionExecutables. And each gets
45         InferredValue, which takes 32 bytes. So it takes 2.7 MB memory footprint.
46
47         In this patch, we introduce a new container InferredValue<>. Which is similar to WriteBarrier<> container, but it replaces
48         the existing InferredValue cells with one pointer size field. The implementation of InferredValue<> is similar to
49         InlineWatchpointSet. But we encode JSCell* too to the pointer data of InlineWatchpointSet. So sizeof(InferredValue<>) is one
50         pointer size while it keeps Watchpoint feature and JSCell holder feature.
51
52         InferredValue<> needs validation in GC finalize phase. So this patch also makes SymbolTable Iso-allocated.
53
54         * JavaScriptCore.xcodeproj/project.pbxproj:
55         * Sources.txt:
56         * bytecode/ObjectAllocationProfileInlines.h:
57         (JSC::ObjectAllocationProfileBase<Derived>::initializeProfile):
58         * bytecode/Watchpoint.h:
59         * dfg/DFGAbstractInterpreterInlines.h:
60         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
61         * dfg/DFGByteCodeParser.cpp:
62         (JSC::DFG::ByteCodeParser::get):
63         (JSC::DFG::ByteCodeParser::parseBlock):
64         * dfg/DFGClobberize.h:
65         (JSC::DFG::clobberize):
66         * dfg/DFGClobbersExitState.cpp:
67         (JSC::DFG::clobbersExitState):
68         * dfg/DFGDesiredWatchpoints.cpp:
69         (JSC::DFG::SymbolTableAdaptor::add):
70         (JSC::DFG::FunctionExecutableAdaptor::add):
71         (JSC::DFG::DesiredWatchpoints::addLazily):
72         (JSC::DFG::DesiredWatchpoints::reallyAdd):
73         (JSC::DFG::DesiredWatchpoints::areStillValid const):
74         (JSC::DFG::DesiredWatchpoints::dumpInContext const):
75         (JSC::DFG::InferredValueAdaptor::add): Deleted.
76         * dfg/DFGDesiredWatchpoints.h:
77         (JSC::DFG::SymbolTableAdaptor::hasBeenInvalidated):
78         (JSC::DFG::SymbolTableAdaptor::dumpInContext):
79         (JSC::DFG::FunctionExecutableAdaptor::hasBeenInvalidated):
80         (JSC::DFG::FunctionExecutableAdaptor::dumpInContext):
81         (JSC::DFG::DesiredWatchpoints::isWatched):
82         (JSC::DFG::InferredValueAdaptor::hasBeenInvalidated): Deleted.
83         (JSC::DFG::InferredValueAdaptor::dumpInContext): Deleted.
84         * dfg/DFGObjectAllocationSinkingPhase.cpp:
85         * dfg/DFGSpeculativeJIT.cpp:
86         (JSC::DFG::SpeculativeJIT::compileNewFunction):
87         (JSC::DFG::SpeculativeJIT::compileCreateActivation):
88         * ftl/FTLLowerDFGToB3.cpp:
89         (JSC::FTL::DFG::LowerDFGToB3::compileCreateActivation):
90         (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
91         * heap/Heap.cpp:
92         (JSC::Heap::finalizeUnconditionalFinalizers):
93         * runtime/FunctionExecutable.cpp:
94         (JSC::FunctionExecutable::FunctionExecutable):
95         (JSC::FunctionExecutable::finishCreation):
96         (JSC::FunctionExecutable::visitChildren):
97         * runtime/FunctionExecutable.h:
98         * runtime/FunctionExecutableInlines.h: Copied from Source/JavaScriptCore/runtime/InferredValueInlines.h.
99         (JSC::FunctionExecutable::finalizeUnconditionally):
100         * runtime/InferredValue.cpp: Removed.
101         * runtime/InferredValue.h:
102         (JSC::InferredValue::inferredValue):
103         (JSC::InferredValue::InferredValue):
104         (JSC::InferredValue::~InferredValue):
105         (JSC::InferredValue::stateOnJSThread const):
106         (JSC::InferredValue::state const):
107         (JSC::InferredValue::hasBeenInvalidated const):
108         (JSC::InferredValue::isStillValid const):
109         (JSC::InferredValue::invalidate):
110         (JSC::InferredValue::isBeingWatched const):
111         (JSC::InferredValue::notifyWrite):
112         (JSC::InferredValue::isThin):
113         (JSC::InferredValue::isFat):
114         (JSC::InferredValue::decodeState):
115         (JSC::InferredValue::encodeState):
116         (JSC::InferredValue::isThin const):
117         (JSC::InferredValue::isFat const):
118         (JSC::InferredValue::fat):
119         (JSC::InferredValue::fat const):
120         (JSC::InferredValue::inflate):
121         (JSC::InferredValue<JSCellType>::InferredValueWatchpointSet::notifyWriteSlow):
122         (JSC::InferredValue<JSCellType>::notifyWriteSlow):
123         (JSC::InferredValue<JSCellType>::add):
124         (JSC::InferredValue<JSCellType>::inflateSlow):
125         (JSC::InferredValue<JSCellType>::freeFat):
126         * runtime/InferredValueInlines.h:
127         (JSC::InferredValue<JSCellType>::finalizeUnconditionally):
128         (JSC::InferredValue::finalizeUnconditionally): Deleted.
129         * runtime/JSFunctionInlines.h:
130         (JSC::JSFunction::createWithInvalidatedReallocationWatchpoint):
131         * runtime/JSSymbolTableObject.h:
132         (JSC::JSSymbolTableObject::setSymbolTable):
133         * runtime/SymbolTable.cpp:
134         (JSC::SymbolTable::finishCreation):
135         (JSC::SymbolTable::visitChildren):
136         * runtime/SymbolTable.h:
137         * runtime/SymbolTableInlines.h: Copied from Source/JavaScriptCore/runtime/InferredValueInlines.h.
138         (JSC::SymbolTable::finalizeUnconditionally):
139         * runtime/VM.cpp:
140         (JSC::VM::VM):
141         * runtime/VM.h:
142
143 2019-06-04  Tadeu Zagallo  <tzagallo@apple.com>
144
145         Argument elimination should check for negative indices in GetByVal
146         https://bugs.webkit.org/show_bug.cgi?id=198302
147         <rdar://problem/51188095>
148
149         Reviewed by Filip Pizlo.
150
151         In DFG::ArgumentEliminationPhase, the index is treated as unsigned, but there's no check
152         for overflow in the addition. In compileGetMyArgumentByVal, there's a check for overflow,
153         but the index is treated as signed, resulting in an index lower than numberOfArgumentsToSkip.
154
155         * dfg/DFGArgumentsEliminationPhase.cpp:
156         * ftl/FTLLowerDFGToB3.cpp:
157         (JSC::FTL::DFG::LowerDFGToB3::compileGetMyArgumentByVal):
158
159 2019-06-04  Tadeu Zagallo  <tzagallo@apple.com>
160
161         JSScript should not keep bytecode cache in memory
162         https://bugs.webkit.org/show_bug.cgi?id=198482
163
164         Reviewed by Saam Barati.
165
166         When JSScript writes to the cache, we keep the in-memory serialized bytecode alive.
167         Instead, we should only ever hold the memory mapped bytecode cache to avoid using
168         too much memory.
169
170         * API/JSScript.mm:
171         (-[JSScript writeCache:]):
172         * API/tests/testapi.mm:
173         (testBytecodeCacheWithSyntaxError):
174         * CMakeLists.txt:
175         * JavaScriptCore.xcodeproj/project.pbxproj:
176         * Sources.txt:
177         * jsc.cpp:
178         * parser/SourceProvider.h:
179         * runtime/BytecodeCacheError.cpp: Added.
180         (JSC::BytecodeCacheError::StandardError::isValid const):
181         (JSC::BytecodeCacheError::StandardError::message const):
182         (JSC::BytecodeCacheError::WriteError::isValid const):
183         (JSC::BytecodeCacheError::WriteError::message const):
184         (JSC::BytecodeCacheError::operator=):
185         (JSC::BytecodeCacheError::isValid const):
186         (JSC::BytecodeCacheError::message const):
187         * runtime/BytecodeCacheError.h: Added.
188         (JSC::BytecodeCacheError::StandardError::StandardError):
189         (JSC::BytecodeCacheError::WriteError::WriteError):
190         * runtime/CachedBytecode.h:
191         (JSC::CachedBytecode::create):
192         * runtime/CachedTypes.cpp:
193         (JSC::Encoder::Encoder):
194         (JSC::Encoder::release):
195         (JSC::Encoder::releaseMapped):
196         (JSC::encodeCodeBlock):
197         (JSC::encodeFunctionCodeBlock):
198         * runtime/CachedTypes.h:
199         * runtime/CodeCache.cpp:
200         (JSC::serializeBytecode):
201         * runtime/CodeCache.h:
202         * runtime/Completion.cpp:
203         (JSC::generateProgramBytecode):
204         (JSC::generateModuleBytecode):
205         * runtime/Completion.h:
206
207 2019-06-03  Caio Lima  <ticaiolima@gmail.com>
208
209         [ESNext][BigInt] Implement support for "**"
210         https://bugs.webkit.org/show_bug.cgi?id=190799
211
212         Reviewed by Saam Barati.
213
214         We are introducing support for BigInt into "**" operator. This Patch
215         also includes changes into DFG, introducing a new node "ValuePow" that
216         is responsible to handle UntypedUse and BigIntUse.
217
218         * dfg/DFGAbstractInterpreterInlines.h:
219         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
220
221         ValuePow(Untyped, Untyped) still can propagate constant if AI proves
222         it. We are doing so if AI proves rhs and lhs as numbers.
223
224         * dfg/DFGByteCodeParser.cpp:
225         (JSC::DFG::ByteCodeParser::parseBlock):
226
227         When compiling op_pow, we first verify if rhs and lhs can be any Int
228         or number. If this happen, we emit ArithPow, otherwise we fallback to
229         ValuePow and rely on fixup to convert it to ArithPow if possible.
230
231         * dfg/DFGClobberize.h:
232         (JSC::DFG::clobberize):
233
234         We only clobberize world if ValuePow is UntypedUse. Otherwise, we can
235         properly support CSE.
236
237         * dfg/DFGDoesGC.cpp:
238         (JSC::DFG::doesGC):
239
240         JSBigInt::exponentiate allocates JSBigInts to perform calculation and
241         it can trigger GC. ValuePow(UntypedUse) can trigger GC because it can
242         execute user code.
243
244         * dfg/DFGFixupPhase.cpp:
245         (JSC::DFG::FixupPhase::fixupArithPow):
246         (JSC::DFG::FixupPhase::fixupNode):
247         * dfg/DFGNodeType.h:
248         * dfg/DFGOperations.cpp:
249         * dfg/DFGOperations.h:
250         * dfg/DFGPredictionPropagationPhase.cpp:
251         * dfg/DFGSafeToExecute.h:
252         (JSC::DFG::safeToExecute):
253         * dfg/DFGSpeculativeJIT.cpp:
254         (JSC::DFG::SpeculativeJIT::compileValuePow):
255         * dfg/DFGSpeculativeJIT.h:
256         * dfg/DFGSpeculativeJIT32_64.cpp:
257         (JSC::DFG::SpeculativeJIT::compile):
258         * dfg/DFGSpeculativeJIT64.cpp:
259         (JSC::DFG::SpeculativeJIT::compile):
260         * dfg/DFGValidate.cpp:
261         * ftl/FTLCapabilities.cpp:
262         (JSC::FTL::canCompile):
263         * ftl/FTLLowerDFGToB3.cpp:
264         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
265         (JSC::FTL::DFG::LowerDFGToB3::compileValuePow):
266         * runtime/CommonSlowPaths.cpp:
267         (JSC::SLOW_PATH_DECL):
268
269         We are adding proper support to BigInt on op_pow. The specification
270         defines that we can only apply pow when both operands have the same
271         type after calling ToNumeric().
272
273         * runtime/JSBigInt.cpp:
274         (JSC::JSBigInt::exponentiate):
275         * runtime/JSBigInt.h:
276
277 2019-06-03  Yusuke Suzuki  <ysuzuki@apple.com>
278
279         [JSC] JSObject::attemptToInterceptPutByIndexOnHole should use getPrototype instead of getPrototypeDirect
280         https://bugs.webkit.org/show_bug.cgi?id=198477
281         <rdar://problem/51299504>
282
283         Reviewed by Saam Barati.
284
285         JSObject::attemptToInterceptPutByIndexOnHole uses getPrototypeDirect, but it should use getPrototype to
286         handle getPrototype methods in derived JSObject classes correctly.
287
288         * runtime/JSArrayInlines.h:
289         (JSC::JSArray::pushInline):
290         * runtime/JSObject.cpp:
291         (JSC::JSObject::putByIndex):
292         (JSC::JSObject::attemptToInterceptPutByIndexOnHoleForPrototype):
293         (JSC::JSObject::attemptToInterceptPutByIndexOnHole):
294         (JSC::JSObject::putByIndexBeyondVectorLength):
295
296 2019-06-03  Don Olmstead  <don.olmstead@sony.com>
297
298         [CMake] Add WebKit::JavaScriptCore target
299         https://bugs.webkit.org/show_bug.cgi?id=198403
300
301         Reviewed by Konstantin Tokarev.
302
303         Create the WebKit::JavaScriptCore target and use that to propagate headers. Use
304         WEBKIT_COPY_FILES instead of WEBKIT_MAKE_FORWARDING_HEADERS.
305
306         * CMakeLists.txt:
307         * shell/CMakeLists.txt:
308
309 2019-06-03  Commit Queue  <commit-queue@webkit.org>
310
311         Unreviewed, rolling out r246022.
312         https://bugs.webkit.org/show_bug.cgi?id=198486
313
314         Causing Internal build failures and JSC test failures
315         (Requested by ShawnRoberts on #webkit).
316
317         Reverted changeset:
318
319         "Reenable Gigacage on ARM64."
320         https://bugs.webkit.org/show_bug.cgi?id=198453
321         https://trac.webkit.org/changeset/246022
322
323 2019-06-03  Darin Adler  <darin@apple.com>
324
325         Finish cleanup of String::number for floating point
326         https://bugs.webkit.org/show_bug.cgi?id=198471
327
328         Reviewed by Yusuke Suzuki.
329
330         * dfg/DFGStrengthReductionPhase.cpp:
331         (JSC::DFG::StrengthReductionPhase::handleNode): Use String::number instead of
332         String::numberToStringECMAScript, since that's now the default.
333         * parser/ParserArena.h:
334         (JSC::IdentifierArena::makeNumericIdentifier): Ditto.
335         * runtime/JSONObject.cpp:
336         (JSC::Stringifier::appendStringifiedValue): Use appendNumber instead of
337         builder.appendECMAScriptNumber, since that's now the default.
338         * runtime/NumberPrototype.cpp:
339         (JSC::toStringWithRadix): Use String::number instead of
340         String::numberToStringECMAScript, since that's now the default.
341         (JSC::numberProtoFuncToExponential): Ditto.
342         (JSC::numberProtoFuncToFixed): Ditto.
343         (JSC::numberProtoFuncToPrecision): Ditto.
344         (JSC::numberToStringInternal): Ditto.
345         * runtime/NumericStrings.h:
346         (JSC::NumericStrings::add): Ditto.
347         * wasm/WasmBBQPlan.cpp:
348         (JSC::Wasm::BBQPlan::prepare): Ditto.
349
350 2019-06-02  Yusuke Suzuki  <ysuzuki@apple.com>
351
352         [JSC] Crash explicitly if StructureIDs are exhausted
353         https://bugs.webkit.org/show_bug.cgi?id=198467
354
355         Reviewed by Sam Weinig.
356
357         When StructureIDTable::m_size reaches to s_maximumNumberOfStructures, newCapacity in resize function is also capped with s_maximumNumberOfStructures.
358         So m_size == newCapacity. In that case, the following code in resize function, `makeFreeListFromRange(m_size, m_capacity - 1);` starts executing the
359         wrong code.
360
361         Currently, this is safe. We immediately execute the wrong code in makeFreeListFromRange, and crash with zero division. But we should not rely on
362         this crash, and instead we should explicitly crash because we exhaust StructureIDs.
363
364         This patch inserts RELEASE_ASSERT for `m_size < newCapacity` status to ensure that resize is always extending the table.
365
366         In practice, this crash does not happen in Safari because Safari has memory footprint limit. To exhaust StructureIDs, we need to allocate massive
367         amount of Structures, and it exceeds the memory footprint limit and the process will be killed.
368
369         * runtime/StructureIDTable.cpp:
370         (JSC::StructureIDTable::resize):
371
372 2019-06-02  Keith Miller  <keith_miller@apple.com>
373
374         Reenable Gigacage on ARM64.
375         https://bugs.webkit.org/show_bug.cgi?id=198453
376
377         Reviewed by Filip Pizlo.
378
379         This patch adds back Gigacaging on Apple's ARM64 ports. Unlike the
380         old Gigacage however, arm64e uses both Gigacaging and PAC. Since
381         Gigacaging would otherwise strip a PAC failed authenticate bit we
382         force a load of the pointer into some garbage register.
383
384         * dfg/DFGSpeculativeJIT.cpp:
385         (JSC::DFG::SpeculativeJIT::jumpForTypedArrayIsNeuteredIfOutOfBounds):
386         (JSC::DFG::SpeculativeJIT::cageTypedArrayStorage):
387         * ftl/FTLLowerDFGToB3.cpp:
388         (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
389         (JSC::FTL::DFG::LowerDFGToB3::untagArrayPtr):
390         (JSC::FTL::DFG::LowerDFGToB3::caged):
391         * jit/AssemblyHelpers.h:
392         (JSC::AssemblyHelpers::cageConditionally):
393         * llint/LowLevelInterpreter64.asm:
394
395 2019-06-02  Tadeu Zagallo  <tzagallo@apple.com>
396
397         CachedMetadataTable::decode leaks empty tables
398         https://bugs.webkit.org/show_bug.cgi?id=198465
399         <rdar://problem/51307673>
400
401         Reviewed by Yusuke Suzuki.
402
403         CachedMetadataTable::decode creates the metadata and never calls finalize on it.
404         This leaks the underlying UnlinkedMetadataTable buffer when m_hasMetadata is false,
405         since the buffer would be freed in finalize instead of in the destructor.
406
407         * bytecode/UnlinkedMetadataTable.h:
408         (JSC::UnlinkedMetadataTable::empty):
409         * bytecode/UnlinkedMetadataTableInlines.h:
410         (JSC::UnlinkedMetadataTable::UnlinkedMetadataTable):
411         * runtime/CachedTypes.cpp:
412         (JSC::CachedMetadataTable::decode const):
413
414 2019-05-31  Yusuke Suzuki  <ysuzuki@apple.com>
415
416         Unreviewed, fix setEntryAddressCommon register usage in LLInt ASM Windows 64
417         https://bugs.webkit.org/show_bug.cgi?id=197979
418
419         * llint/LowLevelInterpreter.asm:
420         * offlineasm/x86.rb:
421
422 2019-05-31  Stephan Szabo  <stephan.szabo@sony.com>
423
424         [PlayStation] Support internal test runner for JSC tests
425         https://bugs.webkit.org/show_bug.cgi?id=198386
426
427         Reviewed by Alex Christensen.
428
429         Support using our test runner with our wrapper library
430         to run multiple tests sequentially in one execution. With
431         default arguments, will run as normal, but with special
432         arguments will shift into this mode.
433
434         * runtime/Options.h:
435         Export the default values of the JSC options similar
436         to the values for resetting the values between tests.
437         * shell/PlatformPlayStation.cmake:
438         * shell/playstation/TestShell.cpp: Added.
439         (setupTestRun): Function to set up the system before starting the tests
440         (preTest): Function for setting up individual test
441         (runTest): Function to run a test execution
442         (postTest): Function for shutdown of individual test
443         (shutdownTestRun): Function for shutting down the system after test run completes.
444
445 2019-05-31  Don Olmstead  <don.olmstead@sony.com>
446
447         [CMake] Add WebKit::WTF target
448         https://bugs.webkit.org/show_bug.cgi?id=198400
449
450         Reviewed by Konstantin Tokarev.
451
452         Use the WebKit::WTF target.
453
454         * CMakeLists.txt:
455         * shell/CMakeLists.txt:
456
457 2019-05-30  Devin Rousso  <drousso@apple.com>
458
459         Web Inspector: Audit: there should be a default test for WebInspectorAudit.Resources functionality
460         https://bugs.webkit.org/show_bug.cgi?id=196710
461         <rdar://problem/49712348>
462
463         Reviewed by Joseph Pecoraro.
464
465         * inspector/protocol/Audit.json:
466         Increment Audit version.
467
468 2019-05-30  Devin Rousso  <drousso@apple.com>
469
470         Web Inspector: Audit: tests are unable to get the current Audit version
471         https://bugs.webkit.org/show_bug.cgi?id=198270
472
473         Reviewed by Timothy Hatcher.
474
475         Expose the Audit version number through the `WebInspectorObject` that's injected into tests
476         so that they can decide at runtime whether they're supported (e.g. the `unsupported` result).
477
478         * inspector/agents/InspectorAuditAgent.h:
479         * inspector/agents/InspectorAuditAgent.cpp:
480         (Inspector::InspectorAuditAgent::populateAuditObject):
481
482 2019-05-30  Tadeu Zagallo  <tzagallo@apple.com> and Yusuke Suzuki  <ysuzuki@apple.com>
483
484         [JSC] Implement op_wide16 / op_wide32 and introduce 16bit version bytecode
485         https://bugs.webkit.org/show_bug.cgi?id=197979
486
487         Reviewed by Filip Pizlo.
488
489         This patch introduces 16bit bytecode size. Previously, we had two versions of bytecodes, 8bit and 32bit. However,
490         in Gmail, we found that a lot of bytecodes get 32bit because they do not fit in 8bit. 8bit is very small and large
491         function easily emits a lot of 32bit bytecodes because of large VirtualRegister number etc. But they almost always
492         fit in 16bit. If we can have 16bit version of bytecode, we can make most of the current 32bit bytecodes 16bit and
493         save memory.
494
495         We rename rename op_wide to op_wide32 and introduce op_wide16. The mechanism is similar to old op_wide. When we
496         get op_wide16, the following bytecode data is 16bit, and we execute 16bit version of bytecode in LLInt.
497
498         We also disable this op_wide16 feature in Windows CLoop, which is used in AppleWin port. When the code size of
499         CLoop::execute increases, MSVC starts generating CLoop::execute function with very large stack allocation
500         requirement. Even before introducing this 16bit bytecode, CLoop::execute in AppleWin takes almost 100KB stack
501         height. After introducing this, it becomes 160KB. While the semantics of the function is correctly compiled,
502         such a large stack allocation is not essentially necessary, and this leads to stack overflow errors quite easily,
503         and tests fail with AppleWin port because it starts throwing stack overflow range error in various places.
504         In this patch, for now, we just disable op_wide16 feature for AppleWin so that CLoop::execute takes 100KB
505         stack allocation because this patch is not focusing on fixing AppleWin's CLoop issue. We introduce a new backend
506         type for LLInt, "C_LOOP_WIN". "C_LOOP_WIN" do not generate wide16 version of code to reduce the code size of
507         CLoop::execute. In the future, we should investigate whether this MSVC issue is fixed in Visual Studio 2019.
508         Or we should consider always enabling ASM LLInt for Windows.
509
510         This patch improves Gmail by 7MB at least.
511
512         * CMakeLists.txt:
513         * bytecode/BytecodeConventions.h:
514         * bytecode/BytecodeDumper.cpp:
515         (JSC::BytecodeDumper<Block>::dumpBlock):
516         * bytecode/BytecodeList.rb:
517         * bytecode/BytecodeRewriter.h:
518         (JSC::BytecodeRewriter::Fragment::align):
519         * bytecode/BytecodeUseDef.h:
520         (JSC::computeUsesForBytecodeOffset):
521         (JSC::computeDefsForBytecodeOffset):
522         * bytecode/CodeBlock.cpp:
523         (JSC::CodeBlock::finishCreation):
524         * bytecode/CodeBlock.h:
525         (JSC::CodeBlock::metadataTable const):
526         * bytecode/Fits.h:
527         * bytecode/Instruction.h:
528         (JSC::Instruction::opcodeID const):
529         (JSC::Instruction::isWide16 const):
530         (JSC::Instruction::isWide32 const):
531         (JSC::Instruction::hasMetadata const):
532         (JSC::Instruction::sizeShiftAmount const):
533         (JSC::Instruction::size const):
534         (JSC::Instruction::wide16 const):
535         (JSC::Instruction::wide32 const):
536         (JSC::Instruction::isWide const): Deleted.
537         (JSC::Instruction::wide const): Deleted.
538         * bytecode/InstructionStream.h:
539         (JSC::InstructionStreamWriter::write):
540         * bytecode/Opcode.h:
541         * bytecode/OpcodeSize.h:
542         * bytecompiler/BytecodeGenerator.cpp:
543         (JSC::BytecodeGenerator::alignWideOpcode16):
544         (JSC::BytecodeGenerator::alignWideOpcode32):
545         (JSC::BytecodeGenerator::emitGetByVal): Previously, we always emit 32bit op_get_by_val for bytecodes in `for-in` context because
546         its operand can be replaced to the other VirtualRegister later. But if we know that replacing VirtualRegister can fit in 8bit / 16bit
547         a-priori, we should not emit 32bit version. We expose OpXXX::checkWithoutMetadataID to check whether we could potentially compact
548         the bytecode for the given operands.
549
550         (JSC::BytecodeGenerator::emitYieldPoint):
551         (JSC::StructureForInContext::finalize):
552         (JSC::BytecodeGenerator::alignWideOpcode): Deleted.
553         * bytecompiler/BytecodeGenerator.h:
554         (JSC::BytecodeGenerator::write):
555         * dfg/DFGCapabilities.cpp:
556         (JSC::DFG::capabilityLevel):
557         * generator/Argument.rb:
558         * generator/DSL.rb:
559         * generator/Metadata.rb:
560         * generator/Opcode.rb: A little bit weird but checkImpl's argument must be reference. We are relying on that BoundLabel is once modified in
561         this check phase, and the modified BoundLabel will be used when emitting the code. If checkImpl copies the passed BoundLabel, this modification
562         will be discarded in this checkImpl function and make the code generation broken.
563
564         * generator/Section.rb:
565         * jit/JITExceptions.cpp:
566         (JSC::genericUnwind):
567         * llint/LLIntData.cpp:
568         (JSC::LLInt::initialize):
569         * llint/LLIntData.h:
570         (JSC::LLInt::opcodeMapWide16):
571         (JSC::LLInt::opcodeMapWide32):
572         (JSC::LLInt::getOpcodeWide16):
573         (JSC::LLInt::getOpcodeWide32):
574         (JSC::LLInt::getWide16CodePtr):
575         (JSC::LLInt::getWide32CodePtr):
576         (JSC::LLInt::opcodeMapWide): Deleted.
577         (JSC::LLInt::getOpcodeWide): Deleted.
578         (JSC::LLInt::getWideCodePtr): Deleted.
579         * llint/LLIntOfflineAsmConfig.h:
580         * llint/LLIntSlowPaths.cpp:
581         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
582         * llint/LLIntSlowPaths.h:
583         * llint/LowLevelInterpreter.asm:
584         * llint/LowLevelInterpreter.cpp:
585         (JSC::CLoop::execute):
586         * llint/LowLevelInterpreter32_64.asm:
587         * llint/LowLevelInterpreter64.asm:
588         * offlineasm/arm.rb:
589         * offlineasm/arm64.rb:
590         * offlineasm/asm.rb:
591         * offlineasm/backends.rb:
592         * offlineasm/cloop.rb:
593         * offlineasm/instructions.rb:
594         * offlineasm/mips.rb:
595         * offlineasm/x86.rb: Load operation with sign extension should also have the extended size information. For example, loadbs should be
596         converted to loadbsi for 32bit sign extension (and loadbsq for 64bit sign extension). And use loadbsq / loadhsq for loading VirtualRegister
597         information in LowLevelInterpreter64 since they will be used for pointer arithmetic and they are using machine register width.
598
599         * parser/ResultType.h:
600         (JSC::OperandTypes::OperandTypes):
601         (JSC::OperandTypes::first const):
602         (JSC::OperandTypes::second const):
603         (JSC::OperandTypes::bits):
604         (JSC::OperandTypes::fromBits):
605         (): Deleted.
606         (JSC::OperandTypes::toInt): Deleted.
607         (JSC::OperandTypes::fromInt): Deleted.
608         We reduce sizeof(OperandTypes) from unsigned to uint16_t, which guarantees that OperandTypes always fit in 16bit bytecode.
609
610 2019-05-30  Justin Michaud  <justin_michaud@apple.com>
611
612         oss-fuzz: jsc: Issue 15016: jsc: Abrt in JSC::Wasm::AirIRGenerator::addLocal (15016)
613         https://bugs.webkit.org/show_bug.cgi?id=198355
614
615         Reviewed by Saam Barati.
616
617         Fix missing anyref case in addLocal.
618
619         * wasm/WasmAirIRGenerator.cpp:
620         (JSC::Wasm::AirIRGenerator::addLocal):
621
622 2019-05-29  Don Olmstead  <don.olmstead@sony.com>
623
624         Remove ENABLE definitions from WebKit config files
625         https://bugs.webkit.org/show_bug.cgi?id=197858
626
627         Reviewed by Simon Fraser.
628
629         Sync FeatureDefines.xcconfig.
630
631         * Configurations/FeatureDefines.xcconfig:
632
633 2019-05-28  Dean Jackson  <dino@apple.com>
634
635         Implement Promise.allSettled
636         https://bugs.webkit.org/show_bug.cgi?id=197600
637         <rdar://problem/50483885>
638
639         Reviewed by Keith Miller.
640
641         Implement Promise.allSettled
642         https://github.com/tc39/proposal-promise-allSettled/
643
644         Shipping in Firefox since version 68.
645         Shipping in V8 since https://chromium.googlesource.com/v8/v8.git/+/1f6d27e8df819b448712dface6ad367fb8de426b
646
647         * builtins/PromiseConstructor.js:
648         (allSettled.newResolveRejectElements.resolveElement):
649         (allSettled.newResolveRejectElements.rejectElement):
650         (allSettled.newResolveRejectElements):
651         (allSettled): Added.
652         * runtime/JSPromiseConstructor.cpp: Add ref to allSettled.
653
654 2019-05-28  Michael Saboff  <msaboff@apple.com>
655
656         [YARR] Properly handle RegExp's that require large ParenContext space
657         https://bugs.webkit.org/show_bug.cgi?id=198065
658
659         Reviewed by Keith Miller.
660
661         Changed what happens when we exceed VM::patternContextBufferSize when compiling a RegExp
662         that needs ParenCOntextSpace to fail the RegExp JIT compilation and fall back to the YARR
663         interpreter.  This can save large amounts of JIT memory for a
664         JIT'ed function that cannot ever succeed.
665
666         * yarr/YarrJIT.cpp:
667         (JSC::Yarr::YarrGenerator::initParenContextFreeList):
668         (JSC::Yarr::YarrGenerator::compile):
669
670 2019-05-28  Tadeu Zagallo  <tzagallo@apple.com>
671
672         JITOperations putByVal should mark negative array indices as out-of-bounds
673         https://bugs.webkit.org/show_bug.cgi?id=198271
674
675         Reviewed by Saam Barati.
676
677         Similar to what was done to getByVal in r245769, we should also mark put_by_val as out-of-bounds
678         when we exit from DFG for putting to a negative index. This avoids the same scenario where we keep
679         recompiling a CodeBlock with DFG and exiting at the same bytecode.
680
681         This is a 3.7x improvement in the microbenchmark being added: put-by-val-negative-array-index.js.
682
683         * jit/JITOperations.cpp:
684
685 2019-05-28  Yusuke Suzuki  <ysuzuki@apple.com>
686
687         Unreviewed, revert r242070 due to Membuster regression
688         https://bugs.webkit.org/show_bug.cgi?id=195013
689
690         Membuster shows ~0.3% regression.
691
692         * heap/Heap.cpp:
693         (JSC::Heap::Heap):
694         (JSC::Heap::runBeginPhase):
695         * heap/Heap.h:
696         * heap/HeapInlines.h:
697         (JSC::Heap::forEachSlotVisitor):
698         (JSC::Heap::numberOfSlotVisitors): Deleted.
699         * heap/MarkingConstraintSolver.cpp:
700         (JSC::MarkingConstraintSolver::didVisitSomething const):
701         * heap/SlotVisitor.h:
702
703 2019-05-27  Tadeu Zagallo  <tzagallo@apple.com>
704
705         Fix opensource build of testapi
706         https://bugs.webkit.org/show_bug.cgi?id=198256
707
708         Reviewed by Alexey Proskuryakov.
709
710         In r245564, we added custom entitlements to testapi to allow caching
711         bytecode in data vaults, but we should only use the entitlements for
712         internal builds. Otherwises, testapi gets killed on launch. Also fix the
713         formatting for the errors added in the same patch, according to comments
714         in the bug after the patch had already landed.
715
716         * API/JSScript.mm:
717         (validateBytecodeCachePath):
718         * Configurations/ToolExecutable.xcconfig:
719
720 2019-05-25  Tadeu Zagallo  <tzagallo@apple.com>
721
722         JITOperations getByVal should mark negative array indices as out-of-bounds
723         https://bugs.webkit.org/show_bug.cgi?id=198229
724
725         Reviewed by Saam Barati.
726
727         get_by_val with an array or string as base value and a negative index causes DFG to OSR exit,
728         but baseline doesn't mark it as out-of-bounds, since it only considers positive indices. This
729         leads to discarding DFG code, recompiling it and exiting at the same bytecode.
730
731         This is observed in the prepack-wtb subtest of JetStream2. In popContext#CdOhFJ, the last item
732         of the array popped and the new last value is accessed using `array[array.length - 1]`, which
733         is -1 when the array is empty. It shows a ~0.5% progression in JetStream2, but it's within the
734         noise.
735
736         * jit/JITOperations.cpp:
737         (JSC::getByVal):
738
739 2019-05-24  Justin Michaud  <justin_michaud@apple.com>
740
741         [WASM-References] Support Anyref in globals
742         https://bugs.webkit.org/show_bug.cgi?id=198102
743
744         Reviewed by Saam Barati.
745
746         Support anyref for globals, imports and exports. This adds code in B3 and Air to emit a write barrier
747         on the JSWebAssemblyWrapper whenever an anyref global is set. This also fixes a small bug in emitCCall
748         for air where it adds code to the wrong block.
749
750         * wasm/WasmAirIRGenerator.cpp:
751         (JSC::Wasm::AirIRGenerator::emitCCall):
752         (JSC::Wasm::AirIRGenerator::moveOpForValueType):
753         (JSC::Wasm::AirIRGenerator::setGlobal):
754         (JSC::Wasm::AirIRGenerator::emitWriteBarrierForJSWrapper):
755         * wasm/WasmB3IRGenerator.cpp:
756         (JSC::Wasm::B3IRGenerator::setGlobal):
757         (JSC::Wasm::B3IRGenerator::emitWriteBarrierForJSWrapper):
758         * wasm/WasmInstance.cpp:
759         (JSC::Wasm::Instance::Instance):
760         (JSC::Wasm::Instance::setGlobal):
761         * wasm/WasmInstance.h:
762         (JSC::Wasm::Instance::loadI32Global const):
763         (JSC::Wasm::Instance::loadI64Global const):
764         (JSC::Wasm::Instance::setGlobal):
765         (JSC::Wasm::Instance::shouldMarkGlobal):
766         (JSC::Wasm::Instance::numGlobals const):
767         * wasm/WasmSectionParser.cpp:
768         (JSC::Wasm::SectionParser::parseInitExpr):
769         * wasm/js/JSWebAssemblyInstance.cpp:
770         (JSC::JSWebAssemblyInstance::visitChildren):
771         * wasm/js/WebAssemblyModuleRecord.cpp:
772         (JSC::WebAssemblyModuleRecord::link):
773
774 2019-05-23  Devin Rousso  <drousso@apple.com>
775
776         Web Inspector: Overlay: rulers/guides should be shown whenever element selection is enabled
777         https://bugs.webkit.org/show_bug.cgi?id=198088
778
779         Reviewed by Timothy Hatcher.
780
781         When trying to "measure" the absolute position (to the viewport) or relative position (to
782         another element) of a given element, often the easiest way is to enable Element Selection
783         and Show Rulers at the same time.
784
785         This can have the undesired "side-effect" of having the rulers be always present, even when
786         not highlighting any nodes.
787
788         The ideal functionality is to allow the rulers/guides to be shown when element selection is
789         active and a node is hovered, regardless of whether "Show Rulers" is enabled.
790
791         * inspector/protocol/DOM.json:
792         Add an optional `showRulers` parameter to `DOM.setInspectModeEnabled` that supersedes the
793         current value of `Page.setShowRulers` as to whether rulers/guides are shown.
794
795 2019-05-23  Ross Kirsling  <ross.kirsling@sony.com>
796
797         Socket-based RWI should be able to inspect a JSContext
798         https://bugs.webkit.org/show_bug.cgi?id=198197
799
800         Reviewed by Don Olmstead.
801
802         * inspector/remote/socket/RemoteInspectorSocket.cpp:
803         (Inspector::RemoteInspector::listingForInspectionTarget const):
804         Just use the debuggableType strings that WebInspectorUI ultimately wants.
805
806 2019-05-23  Tadeu Zagallo  <tzagallo@apple.com>
807
808         DFG::OSREntry should not perform arity check
809         https://bugs.webkit.org/show_bug.cgi?id=198189
810
811         Reviewed by Saam Barati.
812
813         The check prevents OSR entering from hot loops inside functions that were called
814         with too few arguments.
815
816         * dfg/DFGOSREntry.cpp:
817         (JSC::DFG::prepareOSREntry):
818
819 2019-05-23  Ross Kirsling  <ross.kirsling@sony.com>
820
821         Lexer<T>::parseDecimal ought to ASSERT isASCIIDigit
822         https://bugs.webkit.org/show_bug.cgi?id=198156
823
824         Reviewed by Keith Miller.
825
826         * parser/Lexer.cpp:
827         (JSC::Lexer<T>::parseDecimal):
828         Add ASSERT -- apparently the issue with doing so earlier was simply
829         that m_current can be anything at all when m_buffer8 is non-empty.
830
831         (JSC::Lexer<T>::lexWithoutClearingLineTerminator):
832         Clean up a few things in the vicinity of r245655:
833          - fix token enum values in a couple of error cases added in the last patch
834          - add UNLIKELY for existing error cases that forgot to use it
835          - simplify some control flow
836
837 2019-05-23  Adrian Perez de Castro  <aperez@igalia.com>
838
839         Fix a few missing header inclusions often masked by by unified sources
840         https://bugs.webkit.org/show_bug.cgi?id=198180
841
842         Reviewed by Eric Carlson.
843
844         * assembler/PerfLog.cpp: Add missing <array> header inclusion.
845         * wasm/WasmBinding.cpp: Add missing "WasmCallingConvention.h" inclusion.
846
847 2019-05-23  Tadeu Zagallo  <tzagallo@apple.com>
848
849         createListFromArrayLike should throw if value is not an object
850         https://bugs.webkit.org/show_bug.cgi?id=198138
851
852         Reviewed by Yusuke Suzuki.
853
854         According to the spec[1], createListFromArrayLike should throw a type error if the array-like value
855         passed in is not an object.
856         [1]: https://www.ecma-international.org/ecma-262/9.0/index.html#sec-createlistfromarraylike
857
858         * runtime/JSObjectInlines.h:
859         (JSC::createListFromArrayLike):
860         * runtime/ProxyObject.cpp:
861         (JSC::ProxyObject::performGetOwnPropertyNames):
862         * runtime/ReflectObject.cpp:
863         (JSC::reflectObjectConstruct):
864
865 2019-05-22  Yusuke Suzuki  <ysuzuki@apple.com>
866
867         [JSC] UnlinkedMetadataTable's offset table should be small
868         https://bugs.webkit.org/show_bug.cgi?id=197910
869
870         Reviewed by Saam Barati.
871
872         In Gmail, we found that massive # of UnlinkedMetadataTable (21979 - 24727) exists. Each UnlinkedMetadataTable takes at least 204 bytes
873         because of large (unsinged) offset table. This patch reduces the size of offset table by introducing 16bit version offset table.
874         Previously our code for looking up Metadata is like this.
875
876             offset = offsetTable32[opcode]
877             metadata = (SomeOp::Metadata*)table[offset] + id
878
879         Instead, we introduce uint16_t offset table. The lookup code becomes like this.
880
881             offset = offsetTable16[opcode]
882             if (!offset)
883                 offset = offsetTable32[opcode]
884             metadata = (SomeOp::Metadata*)table[offset] + id
885
886         We use 0 offset as a marker to indicate that we have 32bit offset table. This is OK since 0 offset does not appear since all the offsets
887         included in this table is larger than s_offset16TableSize.
888
889         32bit offset table is allocated only when the offset exceeds 16bit range. It means that this will be used only when Metadata table is larger
890         than almost 64KB. Even in Gmail, such MetadataTable is rare, and additional 32bit offset table size does not matter much in this case since
891         MetadataTable is already so large.
892
893         Based on the # of UnlinkedMetadataTables, this optimization should improve Gmail steady state memory by 2MB.
894
895         * JavaScriptCore.xcodeproj/project.pbxproj:
896         * Sources.txt:
897         * bytecode/MetadataTable.cpp:
898         (JSC::MetadataTable::~MetadataTable):
899         (JSC::MetadataTable::destroy):
900         * bytecode/MetadataTable.h:
901         (JSC::MetadataTable::ref):
902         (JSC::MetadataTable::deref):
903         (JSC::MetadataTable::buffer):
904         (JSC::MetadataTable::is32Bit const):
905         (JSC::MetadataTable::offsetTable16 const):
906         (JSC::MetadataTable::offsetTable32 const):
907         (JSC::MetadataTable::totalSize const):
908         (JSC::MetadataTable::getOffset const):
909         (JSC::MetadataTable::getImpl):
910         (JSC::MetadataTable::ref const): Deleted.
911         (JSC::MetadataTable::deref const): Deleted.
912         * bytecode/Opcode.cpp:
913         * bytecode/UnlinkedMetadataTable.cpp: Added.
914         (JSC::UnlinkedMetadataTable::finalize):
915         * bytecode/UnlinkedMetadataTable.h:
916         (JSC::UnlinkedMetadataTable::create):
917         (JSC::UnlinkedMetadataTable::totalSize const):
918         (JSC::UnlinkedMetadataTable::offsetTableSize const):
919         (JSC::UnlinkedMetadataTable::preprocessBuffer const):
920         (JSC::UnlinkedMetadataTable::buffer const):
921         (JSC::UnlinkedMetadataTable::offsetTable16 const):
922         (JSC::UnlinkedMetadataTable::offsetTable32 const):
923         * bytecode/UnlinkedMetadataTableInlines.h:
924         (JSC::UnlinkedMetadataTable::UnlinkedMetadataTable):
925         (JSC::UnlinkedMetadataTable::addEntry):
926         (JSC::UnlinkedMetadataTable::sizeInBytes):
927         (JSC::UnlinkedMetadataTable::link):
928         (JSC::UnlinkedMetadataTable::unlink):
929         (JSC::UnlinkedMetadataTable::finalize): Deleted.
930         * llint/LowLevelInterpreter.asm:
931         * runtime/CachedTypes.cpp:
932         (JSC::CachedMetadataTable::encode):
933         (JSC::CachedMetadataTable::decode const):
934
935 2019-05-22  Yusuke Suzuki  <ysuzuki@apple.com>
936
937         [JSC] ArrayAllocationProfile should not access to butterfly in concurrent compiler
938         https://bugs.webkit.org/show_bug.cgi?id=197809
939
940         Reviewed by Michael Saboff.
941
942         ArrayAllocationProfile assumes that Butterfly can be accessed concurrently. But this is not correct now
943         since LargeAllocation Butterfly can be realloced. In this patch, we switch profiling array allocations
944         only in the main thread. This allocation profiling is repeatedly called in the main thread's slow path,
945         and it is also called when updating the profiles in the main thread.
946
947         We also rename updateAllPredictionsAndCountLiveness to updateAllValueProfilePredictionsAndCountLiveness
948         since it only cares ValueProfiles.
949
950         * bytecode/ArrayAllocationProfile.cpp:
951         (JSC::ArrayAllocationProfile::updateProfile):
952         * bytecode/ArrayAllocationProfile.h:
953         (JSC::ArrayAllocationProfile::selectIndexingTypeConcurrently):
954         (JSC::ArrayAllocationProfile::selectIndexingType):
955         (JSC::ArrayAllocationProfile::vectorLengthHintConcurrently):
956         (JSC::ArrayAllocationProfile::vectorLengthHint):
957         * bytecode/CodeBlock.cpp:
958         (JSC::CodeBlock::updateAllValueProfilePredictionsAndCountLiveness):
959         (JSC::CodeBlock::updateAllValueProfilePredictions):
960         (JSC::CodeBlock::shouldOptimizeNow):
961         (JSC::CodeBlock::updateAllPredictionsAndCountLiveness): Deleted.
962         * bytecode/CodeBlock.h:
963         * dfg/DFGByteCodeParser.cpp:
964         (JSC::DFG::ByteCodeParser::parseBlock):
965
966 2019-05-22  Yusuke Suzuki  <ysuzuki@apple.com>
967
968         [JSC] Shrink Metadata
969         https://bugs.webkit.org/show_bug.cgi?id=197940
970
971         Reviewed by Michael Saboff.
972
973         We get Metadata related data in Gmail and it turns out the following things.
974
975         1. At peak, MetadataTable eats a lot of bytes (30 MB - 50 MB, sometimes 70 MB while total Gmail footprint is 400 - 500 MB).
976         2. After full GC happens, most of Metadata is destroyed while some are kept. Still keeps 1 MB. But after the GC, # of MetadataTable eventually grows again.
977
978         If we shrink Metadata, we can reduce the peak memory footprint in Gmail.
979
980         This patch shrinks Metadata. This patch first focus on low hanging fruits: it does not include the change removing OSR exit JSValue in ValueProfile.
981         This patch uses fancy bit juggling & leverages nice data types to reduce Metadata, as follows.
982
983         1. ValueProfile is reduced from 32 to 24. It reduces Metadata using ValueProfile.
984         2. ArrayProfile is reduced from 16 to 12. Ditto.
985         3. OpCall::Metadata is reduced from 88 to 64.
986         4. OpGetById::Metadata is reduced from 56 to 40.
987         5. OpToThis::Metadata is reduced from 48 to 32.
988         6. OpNewObject::Metadata is reduced from 32 to 16.
989
990         According to the gathered data, it should reduce 1-2MB in steady state in Gmail, much more in peak memory, ~1 MB in the state just after full GC.
991         It also improves RAMification by 0.3% (6 runs).
992
993         * bytecode/ArrayProfile.cpp:
994         * bytecode/ArrayProfile.h:
995         (JSC::ArrayProfile::ArrayProfile):
996         (JSC::ArrayProfile::bytecodeOffset const): Deleted.
997         (JSC::ArrayProfile::isValid const): Deleted.
998         * bytecode/BytecodeList.rb:
999         * bytecode/CallLinkStatus.cpp:
1000         (JSC::CallLinkStatus::computeFromLLInt):
1001         * bytecode/CodeBlock.cpp:
1002         (JSC::CodeBlock::finishCreation):
1003         (JSC::CodeBlock::finalizeLLIntInlineCaches):
1004         (JSC::CodeBlock::getArrayProfile):
1005         (JSC::CodeBlock::updateAllPredictionsAndCountLiveness):
1006         (JSC::CodeBlock::dumpValueProfiles):
1007         * bytecode/CodeBlock.h:
1008         (JSC::CodeBlock::valueProfileForArgument):
1009         * bytecode/CodeBlockInlines.h:
1010         (JSC::CodeBlock::forEachValueProfile):
1011         (JSC::CodeBlock::forEachArrayProfile):
1012         * bytecode/GetByIdMetadata.h:
1013         We use ProtoLoad's JSObject's high bits to embed hitCountForLLIntCaching and mode, since they
1014         are always zero for ProtoLoad mode.
1015
1016         (): Deleted.
1017         * bytecode/GetByIdStatus.cpp:
1018         (JSC::GetByIdStatus::computeFromLLInt):
1019         * bytecode/LLIntCallLinkInfo.h:
1020         (JSC::LLIntCallLinkInfo::isLinked const):
1021         (JSC::LLIntCallLinkInfo::link):
1022         (JSC::LLIntCallLinkInfo::unlink):
1023         (JSC::LLIntCallLinkInfo::callee const):
1024         (JSC::LLIntCallLinkInfo::lastSeenCallee const):
1025         (JSC::LLIntCallLinkInfo::clearLastSeenCallee):
1026         (JSC::LLIntCallLinkInfo::LLIntCallLinkInfo): Deleted.
1027         (JSC::LLIntCallLinkInfo::isLinked): Deleted.
1028         In LLIntCallLinkInfo, we always set the same value to lastSeenCallee and callee. But later, callee can be cleared.
1029         It means that we can represent them in one value + cleared flag. We encode this flag into the lowest bit of the callee cell so
1030         that we can make them one pointer. We also use PackedRawSentinelNode to get some space, and embed ArrayProfile into this space
1031         to get further memory reduction.
1032
1033         * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
1034         (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::clearLLIntGetByIdCache):
1035         * bytecode/LazyOperandValueProfile.h:
1036         (JSC::LazyOperandValueProfile::LazyOperandValueProfile):
1037         (JSC::LazyOperandValueProfile::key const):
1038         * bytecode/MetadataTable.h:
1039         (JSC::MetadataTable::buffer):
1040         * bytecode/ObjectAllocationProfile.h:
1041         (JSC::ObjectAllocationProfileBase::offsetOfAllocator):
1042         (JSC::ObjectAllocationProfileBase::offsetOfStructure):
1043         (JSC::ObjectAllocationProfileBase::clear):
1044         (JSC::ObjectAllocationProfileBase::visitAggregate):
1045         (JSC::ObjectAllocationProfile::setPrototype):
1046         (JSC::ObjectAllocationProfileWithPrototype::prototype):
1047         (JSC::ObjectAllocationProfileWithPrototype::clear):
1048         (JSC::ObjectAllocationProfileWithPrototype::visitAggregate):
1049         (JSC::ObjectAllocationProfileWithPrototype::setPrototype):
1050         (JSC::ObjectAllocationProfile::offsetOfAllocator): Deleted.
1051         (JSC::ObjectAllocationProfile::offsetOfStructure): Deleted.
1052         (JSC::ObjectAllocationProfile::offsetOfInlineCapacity): Deleted.
1053         (JSC::ObjectAllocationProfile::ObjectAllocationProfile): Deleted.
1054         (JSC::ObjectAllocationProfile::isNull): Deleted.
1055         (JSC::ObjectAllocationProfile::structure): Deleted.
1056         (JSC::ObjectAllocationProfile::prototype): Deleted.
1057         (JSC::ObjectAllocationProfile::inlineCapacity): Deleted.
1058         (JSC::ObjectAllocationProfile::clear): Deleted.
1059         (JSC::ObjectAllocationProfile::visitAggregate): Deleted.
1060         * bytecode/ObjectAllocationProfileInlines.h:
1061         (JSC::ObjectAllocationProfileBase<Derived>::initializeProfile):
1062         (JSC::ObjectAllocationProfileBase<Derived>::possibleDefaultPropertyCount):
1063         (JSC::ObjectAllocationProfile::initializeProfile): Deleted.
1064         (JSC::ObjectAllocationProfile::possibleDefaultPropertyCount): Deleted.
1065         OpNewObject's ObjectAllocationProfile does not need to hold prototype. So we have two versions now, ObjectAllocationProfile and ObjectAllocationProfileWithPrototype
1066         to cut one pointer. We also remove inline capacity since this can be retrieved from Structure.
1067
1068         * bytecode/Opcode.h:
1069         * bytecode/ValueProfile.h:
1070         (JSC::ValueProfileBase::ValueProfileBase):
1071         (JSC::ValueProfileBase::totalNumberOfSamples const):
1072         (JSC::ValueProfileBase::isSampledBefore const):
1073         (JSC::ValueProfileBase::dump):
1074         (JSC::ValueProfileBase::computeUpdatedPrediction):
1075         (JSC::MinimalValueProfile::MinimalValueProfile):
1076         (JSC::ValueProfileWithLogNumberOfBuckets::ValueProfileWithLogNumberOfBuckets):
1077         (JSC::ValueProfile::ValueProfile):
1078         (JSC::getValueProfileBytecodeOffset): Deleted.
1079         Bytecode offset is no longer used. And sample count is not used effectively.
1080
1081         * dfg/DFGByteCodeParser.cpp:
1082         (JSC::DFG::ByteCodeParser::parseBlock):
1083         * dfg/DFGOperations.cpp:
1084         * dfg/DFGSpeculativeJIT.cpp:
1085         (JSC::DFG::SpeculativeJIT::compileCreateThis):
1086         * ftl/FTLAbstractHeapRepository.h:
1087         * jit/JITCall.cpp:
1088         (JSC::JIT::compileSetupFrame):
1089         * jit/JITCall32_64.cpp:
1090         (JSC::JIT::compileSetupFrame):
1091         * jit/JITOpcodes.cpp:
1092         (JSC::JIT::emit_op_catch):
1093         (JSC::JIT::emit_op_to_this):
1094         (JSC::JIT::emit_op_create_this):
1095         * jit/JITOpcodes32_64.cpp:
1096         (JSC::JIT::emit_op_catch):
1097         (JSC::JIT::emit_op_create_this):
1098         (JSC::JIT::emit_op_to_this):
1099         * jit/JITOperations.cpp:
1100         * jit/JITPropertyAccess.cpp:
1101         (JSC::JIT::emit_op_get_by_id):
1102         * llint/LLIntSlowPaths.cpp:
1103         (JSC::LLInt::setupGetByIdPrototypeCache):
1104         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1105         (JSC::LLInt::setUpCall):
1106         * llint/LowLevelInterpreter32_64.asm:
1107         * llint/LowLevelInterpreter64.asm:
1108         * runtime/CommonSlowPaths.cpp:
1109         (JSC::SLOW_PATH_DECL):
1110         * runtime/FunctionRareData.h:
1111         * tools/HeapVerifier.cpp:
1112         (JSC::HeapVerifier::validateJSCell):
1113
1114 2019-05-22  Ross Kirsling  <ross.kirsling@sony.com>
1115
1116         [ESNext] Implement support for Numeric Separators
1117         https://bugs.webkit.org/show_bug.cgi?id=196351
1118
1119         Reviewed by Keith Miller.
1120
1121         Implement the following proposal, which is now Stage 3:
1122           https://github.com/tc39/proposal-numeric-separator
1123
1124         Specifically, this allows `_` to be used as a separator in numeric literals.
1125         It may be inserted arbitrarily without semantic effect, but it may not occur:
1126           - multiple times in a row
1127           - at the beginning or end of the literal
1128           - adjacent to `0x`, `0b`, `0o`, `.`, `e`, or `n`
1129           - after a leading zero (e.g. `0_123`), even in sloppy mode
1130
1131         * parser/Lexer.cpp:
1132         (JSC::isASCIIDigitOrSeparator): Added.
1133         (JSC::isASCIIHexDigitOrSeparator): Added.
1134         (JSC::isASCIIBinaryDigitOrSeparator): Added.
1135         (JSC::isASCIIOctalDigitOrSeparator): Added.
1136         (JSC::Lexer<T>::parseHex):
1137         (JSC::Lexer<T>::parseBinary):
1138         (JSC::Lexer<T>::parseOctal):
1139         (JSC::Lexer<T>::parseDecimal):
1140         (JSC::Lexer<T>::parseNumberAfterDecimalPoint):
1141         (JSC::Lexer<T>::parseNumberAfterExponentIndicator):
1142         (JSC::Lexer<T>::lexWithoutClearingLineTerminator):
1143         * parser/Lexer.h:
1144
1145 2019-05-22  Tadeu Zagallo  <tzagallo@apple.com>
1146
1147         llint_slow_path_get_by_id needs to hold the CodeBlock's lock to update the metadata's mode
1148         https://bugs.webkit.org/show_bug.cgi?id=198120
1149         <rdar://problem/49668795>
1150
1151         Reviewed by Michael Saboff.
1152
1153         There are two places in llint_slow_path_get_by_id where we change the
1154         metadata's mode without holding the CodeBlock's lock. This is an issue
1155         when switching to and from ArrayLength mode, since other places can
1156         either get a pointer to an array profile that will be overwritten or
1157         an array profile that hasn't yet been initialized.
1158
1159         * llint/LLIntSlowPaths.cpp:
1160         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1161
1162 2019-05-22  Commit Queue  <commit-queue@webkit.org>
1163
1164         Unreviewed, rolling out r245634.
1165         https://bugs.webkit.org/show_bug.cgi?id=198140
1166
1167         'This patch makes JSC crash on launch in debug builds'
1168         (Requested by tadeuzagallo on #webkit).
1169
1170         Reverted changeset:
1171
1172         "[ESNext] Implement support for Numeric Separators"
1173         https://bugs.webkit.org/show_bug.cgi?id=196351
1174         https://trac.webkit.org/changeset/245634
1175
1176 2019-05-22 Zagallo  <tzagallo@apple.com>
1177
1178         Fix validateExceptionChecks for CLoop
1179         https://bugs.webkit.org/show_bug.cgi?id=191253
1180
1181         Reviewed by Keith Miller.
1182
1183         validateExceptionChecks relies on the stack position to determine if
1184         an ExceptionScope was going to be handled by LLInt or JIT, but when
1185         running with CLoop, it was comparing VM::topEntryFrame, which was an
1186         address inside the CLoopStack to machine stack. This caused exceptions
1187         to never be checked on x86 and always fail on ARM.
1188
1189         * runtime/CatchScope.h:
1190         * runtime/ExceptionScope.h:
1191         * runtime/ThrowScope.h:
1192         * runtime/VM.cpp:
1193         (JSC::VM::currentCLoopStackPointer const):
1194         * runtime/VM.h:
1195
1196 2019-05-22  Tadeu Zagallo  <tzagallo@apple.com>
1197
1198         Stack-buffer-overflow in decodeURIComponent
1199         https://bugs.webkit.org/show_bug.cgi?id=198109
1200         <rdar://problem/50397550>
1201
1202         Reviewed by Michael Saboff.
1203
1204         Since r244828 we started using U8_MAX_LENGTH to determine the size of the buffer and
1205         U8_COUNT_TRAIL_BYTES when decoding UTF-8 sequences in JSC::decode. However, U8_MAX_LENGTH
1206         is defined as 4 and in pre-60 ICU U8_COUNT_TRAIL_BYTES returns 0..5.
1207
1208         * runtime/JSGlobalObjectFunctions.cpp:
1209         (JSC::decode):
1210
1211 2019-05-22  Yusuke Suzuki  <ysuzuki@apple.com>
1212
1213         Don't clear PropertyNameArray in Proxy code
1214         https://bugs.webkit.org/show_bug.cgi?id=197691
1215
1216         Reviewed by Saam Barati.
1217
1218         ProxyObject::performGetOwnPropertyNames clears the given PropertyNameArray to filter out non-enumerable keys.
1219         But this does not assume that PropertyNameArray already contains the keys collected in the different objects.
1220         We have an assumption that PropertyNameArray is always increasing, and JSPropertyNameEnumerator relies on this.
1221         Since ProxyObject::performGetOwnPropertyNames clears the passed PropertyNameArray which contained the other
1222         keys collected at some point of prototype hierarchy, this breaks JSPropertyNameEnumerator. Let's see the example.
1223
1224         var object = { __proto__: someProxy, someKey: 42 };
1225         // Here, we first collect "someKey" in object. And using the same PropertyNameArray to add more keys from __proto__.
1226         // But Proxy accidentally clears the passed PropertyNameArray, so "someKey" becomes missing.
1227         for (var key in object);
1228
1229         This patch fixes ProxyObject::performGetOwnPropertyNames. Using separate PropertyNameArray to collect keys, and
1230         filtering and adding them to the passed PropertyNameArray later. We also remove PropertyNameArray::reset method
1231         since this breaks JSPropertyNameEnumerator's assumption.
1232
1233         We also fix the issue by changing seenKeys' HashSet<UniquedStringImpl*> to HashSet<RefPtr<UniquedStringImpl>>.
1234         They can be deallocated if it is not added to trapResult later and it is toString-ed result from 'toPropertyKey()'.
1235
1236         * runtime/PropertyNameArray.h:
1237         (JSC::PropertyNameArray::reset): Deleted.
1238         * runtime/ProxyObject.cpp:
1239         (JSC::ProxyObject::performGetOwnPropertyNames):
1240
1241 2019-05-22  Ross Kirsling  <ross.kirsling@sony.com>
1242
1243         [ESNext] Implement support for Numeric Separators
1244         https://bugs.webkit.org/show_bug.cgi?id=196351
1245
1246         Reviewed by Keith Miller.
1247
1248         Implement the following proposal, which is now Stage 3:
1249           https://github.com/tc39/proposal-numeric-separator
1250
1251         Specifically, this allows `_` to be used as a separator in numeric literals.
1252         It may be inserted arbitrarily without semantic effect, but it may not occur:
1253           - multiple times in a row
1254           - at the beginning or end of the literal
1255           - adjacent to `0x`, `0b`, `0o`, `.`, `e`, or `n`
1256           - after a leading zero (e.g. `0_123`), even in sloppy mode
1257
1258         * parser/Lexer.cpp:
1259         (JSC::isASCIIDigitOrSeparator): Added.
1260         (JSC::isASCIIHexDigitOrSeparator): Added.
1261         (JSC::isASCIIBinaryDigitOrSeparator): Added.
1262         (JSC::isASCIIOctalDigitOrSeparator): Added.
1263         (JSC::Lexer<T>::parseHex):
1264         (JSC::Lexer<T>::parseBinary):
1265         (JSC::Lexer<T>::parseOctal):
1266         (JSC::Lexer<T>::parseDecimal):
1267         (JSC::Lexer<T>::parseNumberAfterDecimalPoint):
1268         (JSC::Lexer<T>::parseNumberAfterExponentIndicator):
1269         (JSC::Lexer<T>::lexWithoutClearingLineTerminator):
1270         * parser/Lexer.h:
1271
1272 2019-05-22  Yusuke Suzuki  <ysuzuki@apple.com>
1273
1274         [JSC] ArrayBufferContents::tryAllocate signs the pointer with allocation size and authenticates it with sizeInBytes
1275         https://bugs.webkit.org/show_bug.cgi?id=198101
1276
1277         Reviewed by Michael Saboff.
1278
1279         When we allocate 0-length ArrayBuffer, we allocate 1 byte storage instead because we would like to ensure that
1280         non-neutered ArrayBuffer always have non nullptr. While we allocate a 1 byte storage, this ArrayBuffer says
1281         sizeInBytes = 0. However, we accidentally configure the vector pointer with this 1 byte size in the constructor.
1282         In ARM64E device, we sign the vector pointer with modifier = 1 (1 byte size), and later we authenticate this
1283         pointer with modifier = 0 (sizeInBytes), and fail to authenticate the pointer.
1284
1285         In this patch, we sign the pointer with sizeInBytes so that we correctly authenticate the 0 bytes vector pointer.
1286
1287         * runtime/ArrayBuffer.cpp:
1288         (JSC::ArrayBufferContents::tryAllocate):
1289
1290 2019-05-21  Ross Kirsling  <ross.kirsling@sony.com>
1291
1292         [PlayStation] Don't call fcntl.
1293         https://bugs.webkit.org/show_bug.cgi?id=197961
1294
1295         Reviewed by Fujii Hironori.
1296
1297         * inspector/remote/socket/posix/RemoteInspectorSocketPOSIX.cpp:
1298         (Inspector::Socket::setup):
1299         Use WTF::setCloseOnExec and WTF::setNonBlock.
1300
1301 2019-05-21  Stephan Szabo  <stephan.szabo@sony.com>
1302
1303         [PlayStation] Update initializer for changed port options
1304         https://bugs.webkit.org/show_bug.cgi?id=198057
1305
1306         Reviewed by Ross Kirsling.
1307
1308         * shell/playstation/Initializer.cpp:
1309         (initializer): Remove loading of shared JavaScriptCore
1310         library.
1311
1312 2019-05-21  Tadeu Zagallo  <tzagallo@apple.com>
1313
1314         Fix production build after r245564
1315         https://bugs.webkit.org/show_bug.cgi?id=197898
1316
1317         Reviewed by Keith Miller.
1318
1319         The production configuration should not set CODE_SIGN_IDENTITY.
1320
1321         * Configurations/ToolExecutable.xcconfig:
1322
1323 2019-05-21  Keith Miller  <keith_miller@apple.com>
1324
1325         Unreviewed, add mistakenly ommited initializer.
1326
1327         * runtime/RegExpInlines.h:
1328
1329 2019-05-21  Keith Miller  <keith_miller@apple.com>
1330
1331         Unreviewed build fix add UNUSED_PARAM.
1332
1333         * runtime/RegExpInlines.h:
1334         (JSC::PatternContextBufferHolder::PatternContextBufferHolder):
1335
1336 2019-05-20  Keith Miller  <keith_miller@apple.com>
1337
1338         Cleanup Yarr regexp code around paren contexts.
1339         https://bugs.webkit.org/show_bug.cgi?id=198063
1340
1341         Reviewed by Yusuke Suzuki.
1342
1343         There are three refactoring changes around paren contexts:
1344         1. Make EncodedMatchResult the same type as MatchResult on X86_64 and arm64 and uint64_t elsewhere.
1345         2. All function pointer types for Yarr JIT generated code reserve space for paren contexts.
1346         3. initParenContextFreeList should bail based on VM::patternContextBufferSize as that's the buffer size anyway.
1347
1348         * runtime/MatchResult.h:
1349         (JSC::MatchResult::MatchResult):
1350         * runtime/RegExpInlines.h:
1351         (JSC::PatternContextBufferHolder::PatternContextBufferHolder):
1352         (JSC::PatternContextBufferHolder::~PatternContextBufferHolder):
1353         (JSC::PatternContextBufferHolder::size):
1354         (JSC::RegExp::matchInline):
1355         * runtime/VM.h:
1356         * yarr/YarrJIT.cpp:
1357         (JSC::Yarr::YarrGenerator::initParenContextFreeList):
1358         * yarr/YarrJIT.h:
1359         (JSC::Yarr::YarrCodeBlock::execute):
1360
1361 2019-05-20  Tadeu Zagallo  <tzagallo@apple.com>
1362
1363         Only cache bytecode for API clients in data vaults
1364         https://bugs.webkit.org/show_bug.cgi?id=197898
1365         <rdar://problem/45945449>
1366
1367         Reviewed by Keith Miller.
1368
1369         Enforce that API clients only store cached bytecode in data vaults. This prevents
1370         another process from compromising the current one by tampering with the bytecode.
1371
1372         * API/JSScript.mm:
1373         (validateBytecodeCachePath):
1374         (+[JSScript scriptOfType:withSource:andSourceURL:andBytecodeCache:inVirtualMachine:error:]):
1375         (+[JSScript scriptOfType:memoryMappedFromASCIIFile:withSourceURL:andBytecodeCache:inVirtualMachine:error:]):
1376         * API/tests/testapi.mm:
1377         (cacheFileInDataVault):
1378         (testModuleBytecodeCache):
1379         (testProgramBytecodeCache):
1380         (testBytecodeCacheWithSyntaxError):
1381         (testBytecodeCacheWithSameCacheFileAndDifferentScript):
1382         (testCacheFileFailsWhenItsAlreadyCached):
1383         (testCanCacheManyFilesWithTheSameVM):
1384         (testIsUsingBytecodeCacheAccessor):
1385         (testBytecodeCacheValidation):
1386         (testObjectiveCAPI):
1387         * Configurations/ToolExecutable.xcconfig:
1388         * JavaScriptCore.xcodeproj/project.pbxproj:
1389         * testapi.entitlements: Added.
1390
1391 2019-05-20  Tadeu Zagallo  <tzagallo@apple.com>
1392
1393         Fix 32-bit btyecode cache crashes
1394         https://bugs.webkit.org/show_bug.cgi?id=198035
1395         <rdar://problem/49905560>
1396
1397         Reviewed by Michael Saboff.
1398
1399         There were 2 32-bit issues with the bytecode cache:
1400         - UnlinkedFunctionExecutable::m_cachedCodeBlockForConstructOffset was not initialized.
1401           The code was relying on the other member of the union, `m_unlinkedCodeBlockForConstruct`,
1402           initializing both m_cachedCodeBlockForCallOffset and m_cachedCodeBlockForConstructOffset.
1403           This is undefined behavior and is also incorrect in 32-bit. Since m_unlinkedCodeBlockForConstruct
1404           is 32-bit, it only initializes the first member of the struct.
1405         - Encoder::Page was not aligned at the end. This lead to unaligned allocations on subsequent
1406           pages, since the start of the following page would not be aligned.
1407
1408         * runtime/CachedTypes.cpp:
1409         (JSC::Encoder::release):
1410         (JSC::Encoder::Page::alignEnd):
1411         (JSC::Encoder::allocateNewPage):
1412         (JSC::VariableLengthObject::buffer const):
1413         (JSC::VariableLengthObject::allocate):
1414         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
1415
1416 2019-05-20  Ross Kirsling  <ross.kirsling@sony.com>
1417
1418         [WinCairo] Implement Remote Web Inspector Client.
1419         https://bugs.webkit.org/show_bug.cgi?id=197434
1420
1421         Reviewed by Don Olmstead.
1422
1423         * inspector/remote/socket/RemoteInspectorConnectionClient.cpp:
1424         (Inspector::RemoteInspectorConnectionClient::didAccept): Deleted.
1425         * inspector/remote/socket/RemoteInspectorConnectionClient.h:
1426         (Inspector::RemoteInspectorConnectionClient::didAccept):
1427         * inspector/remote/socket/RemoteInspectorServer.cpp:
1428         (Inspector::RemoteInspectorServer::dispatchMap):
1429
1430 2019-05-20  Carlos Garcia Campos  <cgarcia@igalia.com>
1431
1432         [GLIB] Crash when instantiating a js object registered with jsc_context_register_class on window object cleared
1433         https://bugs.webkit.org/show_bug.cgi?id=198037
1434
1435         Reviewed by Michael Catanzaro.
1436
1437         This happens because JSCClass is keeping a pointer to the JSCContext used when the class is registered, and the
1438         context can be destroyed before the class. We can't a reference to the context, because we don't really want to
1439         keep it alive. The life of the JSCClass is not attached to the JSCContext, but to its wrapped global context, so
1440         we can keep a pointer to the JSGlobalContextRef instead and create a new JSCContext wrapping it when
1441         needed. This patch is also making the context property of JSCClass non-readable, which was always the intention,
1442         that's why there isn't a public getter in the API.
1443
1444         * API/glib/JSCCallbackFunction.cpp:
1445         (JSC::JSCCallbackFunction::construct): Pass the context to jscClassGetOrCreateJSWrapper().
1446         * API/glib/JSCClass.cpp:
1447         (jscClassGetProperty): Remove the getter for context property.
1448         (jscClassSetProperty): Get the JSGlobalContextRef from the given JSCContext.
1449         (jsc_class_class_init): Make context writable only.
1450         (jscClassCreate): Use the passed in context instead of the member.
1451         (jscClassGetOrCreateJSWrapper): It receives now the context as parameter.
1452         (jscClassCreateContextWithJSWrapper): Ditto.
1453         (jscClassCreateConstructor): Get or create a JSCContext for our JSGlobalContextRef.
1454         (jscClassAddMethod): Ditto.
1455         (jsc_class_add_property): Ditto.
1456         * API/glib/JSCClassPrivate.h:
1457         * API/glib/JSCContext.cpp:
1458         (jsc_context_evaluate_in_object): Pass the context to jscClassCreateContextWithJSWrapper().
1459         * API/glib/JSCValue.cpp:
1460         (jsc_value_new_object): Pass the context to jscClassGetOrCreateJSWrapper().
1461
1462 2019-05-19  Tadeu Zagallo  <tzagallo@apple.com>
1463
1464         Add support for %pid in dumpJITMemoryPath
1465         https://bugs.webkit.org/show_bug.cgi?id=198026
1466
1467         Reviewed by Saam Barati.
1468
1469         This is necessary when using dumpJITMemory with Safari. Otherwise, multiple WebContent
1470         processes will try to write to the same file at the same time, which will crash since
1471         the file is open with exclusive locking.
1472
1473         * jit/ExecutableAllocator.cpp:
1474         (JSC::dumpJITMemory):
1475
1476 2019-05-18  Tadeu Zagallo  <tzagallo@apple.com>
1477
1478         Add extra information to dumpJITMemory
1479         https://bugs.webkit.org/show_bug.cgi?id=197998
1480
1481         Reviewed by Saam Barati.
1482
1483         Add ktrace events around the memory dump and mach_absolute_time to link the
1484         events with the entries in the dump. Additionally, add a background queue
1485         to flush on a configurable interval, since the atexit callback does not work
1486         in every situation.
1487
1488         * jit/ExecutableAllocator.cpp:
1489         (JSC::dumpJITMemory):
1490         * runtime/Options.h:
1491
1492 2019-05-17  Justin Michaud  <justin_michaud@apple.com>
1493
1494         [WASM-References] Add support for Anyref in parameters and return types, Ref.null and Ref.is_null for Anyref values.
1495         https://bugs.webkit.org/show_bug.cgi?id=197969
1496
1497         Reviewed by Keith Miller.
1498
1499         Add a new runtime option for wasm references.
1500         Add support for Anyref as a value type.
1501         Add support for Anyref in parameters and return types of Wasm functions. JSValues are marshalled into/out of wasm Anyrefs
1502                 as a black box, except null which becomes a Nullref value. Nullref is not expressible in the bytecode or in the js API.
1503         Add Ref.null and Ref.is_null for Anyref values. Support for these functions with funcrefs is out of scope.
1504
1505         * runtime/Options.h:
1506         * wasm/WasmAirIRGenerator.cpp:
1507         (JSC::Wasm::AirIRGenerator::tmpForType):
1508         (JSC::Wasm::AirIRGenerator::AirIRGenerator):
1509         (JSC::Wasm::AirIRGenerator::addConstant):
1510         (JSC::Wasm::AirIRGenerator::addRefIsNull):
1511         (JSC::Wasm::AirIRGenerator::addReturn):
1512         * wasm/WasmB3IRGenerator.cpp:
1513         (JSC::Wasm::B3IRGenerator::addRefIsNull):
1514         * wasm/WasmCallingConvention.h:
1515         (JSC::Wasm::CallingConventionAir::marshallArgument const):
1516         (JSC::Wasm::CallingConventionAir::setupCall const):
1517         * wasm/WasmFormat.h:
1518         (JSC::Wasm::isValueType):
1519         * wasm/WasmFunctionParser.h:
1520         (JSC::Wasm::FunctionParser<Context>::FunctionParser):
1521         (JSC::Wasm::FunctionParser<Context>::parseExpression):
1522         (JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
1523         * wasm/WasmValidate.cpp:
1524         (JSC::Wasm::Validate::addRefIsNull):
1525         * wasm/generateWasmOpsHeader.py:
1526         (bitSet):
1527         * wasm/js/JSToWasm.cpp:
1528         (JSC::Wasm::createJSToWasmWrapper):
1529         * wasm/js/WasmToJS.cpp:
1530         (JSC::Wasm::wasmToJS):
1531         * wasm/js/WebAssemblyFunction.cpp:
1532         (JSC::callWebAssemblyFunction):
1533         (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
1534         * wasm/wasm.json:
1535
1536 2019-05-17  Don Olmstead  <don.olmstead@sony.com>
1537
1538         [CMake] Use builtin FindICU
1539         https://bugs.webkit.org/show_bug.cgi?id=197934
1540
1541         Reviewed by Michael Catanzaro.
1542
1543         Remove uses of ICU_INCLUDE_DIRS and ICU_LIBRARIES.
1544
1545         * CMakeLists.txt:
1546         * PlatformWin.cmake:
1547
1548 2019-05-17  Keith Rollin  <krollin@apple.com>
1549
1550         Re-enable generate-xcfilelists
1551         https://bugs.webkit.org/show_bug.cgi?id=197933
1552         <rdar://problem/50831677>
1553
1554         Reviewed by Jonathan Bedard.
1555
1556         The following two tasks have been completed, and we can re-enable
1557         generate-xcfilelists:
1558
1559         Bug 197619 <rdar://problem/50507392> Temporarily disable generate-xcfilelists (197619)
1560         Bug 197622 <rdar://problem/50508222> Rewrite generate-xcfilelists in Python (197622)
1561
1562         * Scripts/check-xcfilelists.sh:
1563
1564 2019-05-16  Keith Miller  <keith_miller@apple.com>
1565
1566         Wasm should cage the memory base pointers in structs
1567         https://bugs.webkit.org/show_bug.cgi?id=197620
1568
1569         Reviewed by Saam Barati.
1570
1571         Currently, we use cageConditionally; this only matters for API
1572         users since the web content process cannot disable primitive
1573         gigacage. This patch also adds a set helper for union/intersection
1574         of RegisterSets.
1575
1576         * assembler/CPU.h:
1577         (JSC::isARM64E):
1578         * jit/RegisterSet.h:
1579         (JSC::RegisterSet::set):
1580         * wasm/WasmAirIRGenerator.cpp:
1581         (JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState):
1582         (JSC::Wasm::AirIRGenerator::addCallIndirect):
1583         * wasm/WasmB3IRGenerator.cpp:
1584         (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
1585         (JSC::Wasm::B3IRGenerator::addCallIndirect):
1586         * wasm/WasmBinding.cpp:
1587         (JSC::Wasm::wasmToWasm):
1588         * wasm/WasmInstance.h:
1589         (JSC::Wasm::Instance::cachedMemory const):
1590         (JSC::Wasm::Instance::updateCachedMemory):
1591         * wasm/WasmMemory.cpp:
1592         (JSC::Wasm::Memory::grow):
1593         * wasm/WasmMemory.h:
1594         (JSC::Wasm::Memory::memory const):
1595         * wasm/js/JSToWasm.cpp:
1596         (JSC::Wasm::createJSToWasmWrapper):
1597         * wasm/js/WebAssemblyFunction.cpp:
1598         (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
1599
1600 2019-05-16  David Kilzer  <ddkilzer@apple.com>
1601
1602         REGRESSION (r15133): Fix leak of JSStringRef in minidom
1603         <https://webkit.org/b/197968>
1604         <rdar://problem/50872430>
1605
1606         Reviewed by Joseph Pecoraro.
1607
1608         * API/tests/minidom.c:
1609         (print): Call JSStringRelease() to fix the leak.
1610
1611 2019-05-16  Ross Kirsling  <ross.kirsling@sony.com>
1612
1613         [JSC] Invalid AssignmentTargetType should be an early error.
1614         https://bugs.webkit.org/show_bug.cgi?id=197603
1615
1616         Reviewed by Keith Miller.
1617
1618         Since ES6, expressions like 0++, ++0, 0 = 0, and 0 += 0 are all specified as early errors:
1619           https://tc39.github.io/ecma262/#sec-update-expressions-static-semantics-early-errors
1620           https://tc39.github.io/ecma262/#sec-assignment-operators-static-semantics-early-errors
1621
1622         We currently throw late ReferenceErrors for these -- let's turn them into early SyntaxErrors.
1623         (This is based on the expectation that https://github.com/tc39/ecma262/pull/1527 will be accepted;
1624         if that doesn't come to pass, we can subsequently introduce early ReferenceError and revise these.)
1625
1626         * bytecompiler/NodesCodegen.cpp:
1627         (JSC::PostfixNode::emitBytecode): Add an assert for "function call LHS" case.
1628         (JSC::PrefixNode::emitBytecode): Add an assert for "function call LHS" case.
1629
1630         * parser/ASTBuilder.h:
1631         (JSC::ASTBuilder::isLocation): Added.
1632         (JSC::ASTBuilder::isAssignmentLocation): Fix misleading parameter name.
1633         (JSC::ASTBuilder::isFunctionCall): Added.
1634         (JSC::ASTBuilder::makeAssignNode): Add an assert for "function call LHS" case.
1635         * parser/SyntaxChecker.h:
1636         (JSC::SyntaxChecker::isLocation): Added.
1637         (JSC::SyntaxChecker::isAssignmentLocation): Fix incorrect definition and align with ASTBuilder.
1638         (JSC::SyntaxChecker::isFunctionCall): Added.
1639         * parser/Nodes.h:
1640         (JSC::ExpressionNode::isFunctionCall const): Added.
1641         Ensure that the parser can check whether an expression node is a function call.
1642
1643         * parser/Parser.cpp:
1644         (JSC::Parser<LexerType>::isSimpleAssignmentTarget): Added.
1645         (JSC::Parser<LexerType>::parseAssignmentExpression):
1646         (JSC::Parser<LexerType>::parseUnaryExpression): See below.
1647         * parser/Parser.h:
1648         Throw SyntaxError whenever an assignment or update expression's target is invalid.
1649         Unfortunately, it seems that web compatibility obliges us to exempt the "function call LHS" case in sloppy mode.
1650         (https://github.com/tc39/ecma262/issues/257#issuecomment-195106880)
1651
1652         Additional cleanup items:
1653           - Make use of `semanticFailIfTrue` for `isMetaProperty` checks, as it's equivalent.
1654           - Rename `requiresLExpr` to `hasPrefixUpdateOp` since it's now confusing,
1655             and get rid of `modifiesExpr` since it refers to the exact same condition.
1656           - Stop setting `lastOperator` near the end -- one case was incorrect and regardless neither is used.
1657
1658 2019-05-15  Saam Barati  <sbarati@apple.com>
1659
1660         Bound liveness of SetArgumentMaybe nodes when maximal flush insertion phase is enabled
1661         https://bugs.webkit.org/show_bug.cgi?id=197855
1662         <rdar://problem/50236506>
1663
1664         Reviewed by Michael Saboff.
1665
1666         Maximal flush insertion phase assumes it can extend the live range of
1667         variables. However, this is not true with SetArgumentMaybe nodes, because
1668         they are not guaranteed to demarcate the birth of a variable in the way
1669         that SetArgumentDefinitely does. This caused things to break in SSA conversion
1670         when we wanted to use the result of a SetArgumentMaybe node. To obviate this,
1671         when we're done inlining something with SetArgumentMaybes, we SetLocal(undefined)
1672         to the same set of locals. This caps the live range of the SetArgumentMaybe
1673         and makes it so that extending the live range of the SetLocal is valid.
1674
1675         * dfg/DFGByteCodeParser.cpp:
1676         (JSC::DFG::ByteCodeParser::handleVarargsInlining):
1677
1678 2019-05-14  Keith Miller  <keith_miller@apple.com>
1679
1680         Fix issue with byteOffset on ARM64E
1681         https://bugs.webkit.org/show_bug.cgi?id=197884
1682
1683         Reviewed by Saam Barati.
1684
1685         We forgot to remove the tag from the ArrayBuffer's data
1686         pointer. This corrupted data when computing the offset.  We didn't
1687         catch this because we didn't run any with a non-zero byteOffset in
1688         the JITs.
1689
1690         * dfg/DFGSpeculativeJIT.cpp:
1691         (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
1692         * ftl/FTLLowerDFGToB3.cpp:
1693         (JSC::FTL::DFG::LowerDFGToB3::compileGetTypedArrayByteOffset):
1694         (JSC::FTL::DFG::LowerDFGToB3::untagArrayPtr):
1695         (JSC::FTL::DFG::LowerDFGToB3::removeArrayPtrTag):
1696         (JSC::FTL::DFG::LowerDFGToB3::speculateTypedArrayIsNotNeutered):
1697         * jit/IntrinsicEmitter.cpp:
1698         (JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter):
1699
1700 2019-05-14  Tadeu Zagallo  <tzagallo@apple.com>
1701
1702         REGRESSION (r245249): ASSERTION FAILED: !m_needExceptionCheck seen with stress/proxy-delete.js and stress/proxy-property-descriptor.js
1703         https://bugs.webkit.org/show_bug.cgi?id=197885
1704         <rdar://problem/50770190>
1705
1706         Reviewed by Yusuke Suzuki.
1707
1708         In r245249 we added a throw scope to JSObject::getOwnPropertyDescriptor and its
1709         callers now need to check for exceptions.
1710
1711         * runtime/ProxyObject.cpp:
1712         (JSC::performProxyGet):
1713         (JSC::ProxyObject::performDelete):
1714
1715 2019-05-14  Ross Kirsling  <ross.kirsling@sony.com>
1716
1717         Unreviewed restoration of non-unified build.
1718
1719         * dfg/DFGMinifiedID.h:
1720         * runtime/ObjectToStringAdaptiveStructureWatchpoint.cpp:
1721
1722 2019-05-14  Yusuke Suzuki  <ysuzuki@apple.com>
1723
1724         [JSC] Shrink sizeof(UnlinkedFunctionExecutable) more
1725         https://bugs.webkit.org/show_bug.cgi?id=197833
1726
1727         Reviewed by Darin Adler.
1728
1729         It turns out that Gmail creates so many JSFunctions, FunctionExecutables, and UnlinkedFunctionExecutables.
1730         So we should shrink size of them to save memory. As a first step, this patch reduces the sizeof(UnlinkedFunctionExecutable) more by 16 bytes.
1731
1732         1. We reorder some fields to get 8 bytes. And we use 31 bits for xxx offset things since their maximum size should be within 31 bits due to
1733            String's length & int32_t representation in our parser.
1734
1735         2. We drop m_inferredName and prefer m_ecmaName. The inferred name is used to offer better function name when the function expression lacks
1736            the name, but now ECMAScript has a specified semantics to name those functions with intuitive names. We should use ecmaName consistently,
1737            and should not eat 8 bytes for inferred names in UnlinkedFunctionExecutable.
1738
1739         We also fix generator ecma name.
1740
1741         * bytecode/CodeBlock.cpp:
1742         (JSC::CodeBlock::inferredName const):
1743         * bytecode/InlineCallFrame.cpp:
1744         (JSC::InlineCallFrame::inferredName const):
1745         * bytecode/UnlinkedFunctionExecutable.cpp:
1746         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
1747         * bytecode/UnlinkedFunctionExecutable.h:
1748         * parser/ASTBuilder.h:
1749         (JSC::ASTBuilder::createAssignResolve):
1750         (JSC::ASTBuilder::createGeneratorFunctionBody):
1751         (JSC::ASTBuilder::createGetterOrSetterProperty):
1752         (JSC::ASTBuilder::createProperty):
1753         (JSC::ASTBuilder::tryInferNameInPatternWithIdentifier):
1754         (JSC::ASTBuilder::makeAssignNode):
1755         * parser/Nodes.cpp:
1756         (JSC::FunctionMetadataNode::operator== const):
1757         (JSC::FunctionMetadataNode::dump const):
1758         * parser/Nodes.h:
1759         * runtime/CachedTypes.cpp:
1760         (JSC::CachedFunctionExecutable::ecmaName const):
1761         (JSC::CachedFunctionExecutable::encode):
1762         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
1763         (JSC::CachedFunctionExecutable::inferredName const): Deleted.
1764         * runtime/FunctionExecutable.h:
1765         * runtime/FunctionExecutableDump.cpp:
1766         (JSC::FunctionExecutableDump::dump const):
1767         * runtime/JSFunction.cpp:
1768         (JSC::JSFunction::calculatedDisplayName):
1769         (JSC::getCalculatedDisplayName):
1770         * runtime/SamplingProfiler.cpp:
1771         (JSC::SamplingProfiler::StackFrame::displayName):
1772         (JSC::SamplingProfiler::StackFrame::displayNameForJSONTests):
1773
1774 2019-05-13  Yusuke Suzuki  <ysuzuki@apple.com>
1775
1776         [JSC] Compress JIT related data more by using Packed<>
1777         https://bugs.webkit.org/show_bug.cgi?id=197866
1778
1779         Reviewed by Saam Barati.
1780
1781         This patch leverages Packed<> more to reduce JIT related data size. When we measure memory usage on Gmail, we found that a lot of memory is
1782         consumed in DFG data. This patch attempts to reduce that size by using Packed<> to make various data structure's alignment 1.
1783
1784         * dfg/DFGCommonData.cpp:
1785         (JSC::DFG::CommonData::shrinkToFit): Add more shrinkToFit.
1786         * dfg/DFGMinifiedID.h: Make alignment = 1.
1787         (JSC::DFG::MinifiedID::operator! const):
1788         (JSC::DFG::MinifiedID::operator== const):
1789         (JSC::DFG::MinifiedID::operator!= const):
1790         (JSC::DFG::MinifiedID::operator< const):
1791         (JSC::DFG::MinifiedID::operator> const):
1792         (JSC::DFG::MinifiedID::operator<= const):
1793         (JSC::DFG::MinifiedID::operator>= const):
1794         (JSC::DFG::MinifiedID::hash const):
1795         (JSC::DFG::MinifiedID::dump const):
1796         (JSC::DFG::MinifiedID::isHashTableDeletedValue const):
1797         (JSC::DFG::MinifiedID::bits const):
1798         * dfg/DFGMinifiedIDInlines.h:
1799         (JSC::DFG::MinifiedID::MinifiedID):
1800         * dfg/DFGMinifiedNode.cpp:
1801         (JSC::DFG::MinifiedNode::fromNode): Make sizeof(MinifiedNode) from 16 to 13 with alignment = 1.
1802         * dfg/DFGMinifiedNode.h:
1803         (JSC::DFG::MinifiedNode::id const):
1804         (JSC::DFG::MinifiedNode::hasConstant const):
1805         (JSC::DFG::MinifiedNode::constant const):
1806         (JSC::DFG::MinifiedNode::isPhantomDirectArguments const):
1807         (JSC::DFG::MinifiedNode::isPhantomClonedArguments const):
1808         (JSC::DFG::MinifiedNode::hasInlineCallFrame const):
1809         (JSC::DFG::MinifiedNode::inlineCallFrame const):
1810         (JSC::DFG::MinifiedNode::op const): Deleted.
1811         (JSC::DFG::MinifiedNode::hasInlineCallFrame): Deleted.
1812         * dfg/DFGVariableEvent.h: Make sizeof(VariableEvent) from 12 to 10 with alignment = 1.
1813         (JSC::DFG::VariableEvent::fillGPR):
1814         (JSC::DFG::VariableEvent::fillPair):
1815         (JSC::DFG::VariableEvent::fillFPR):
1816         (JSC::DFG::VariableEvent::birth):
1817         (JSC::DFG::VariableEvent::spill):
1818         (JSC::DFG::VariableEvent::death):
1819         (JSC::DFG::VariableEvent::setLocal):
1820         (JSC::DFG::VariableEvent::movHint):
1821         (JSC::DFG::VariableEvent::id const):
1822         (JSC::DFG::VariableEvent::gpr const):
1823         (JSC::DFG::VariableEvent::tagGPR const):
1824         (JSC::DFG::VariableEvent::payloadGPR const):
1825         (JSC::DFG::VariableEvent::fpr const):
1826         (JSC::DFG::VariableEvent::spillRegister const):
1827         (JSC::DFG::VariableEvent::bytecodeRegister const):
1828         (JSC::DFG::VariableEvent::machineRegister const):
1829         (JSC::DFG::VariableEvent::variableRepresentation const):
1830         * dfg/DFGVariableEventStream.cpp:
1831         (JSC::DFG::tryToSetConstantRecovery):
1832
1833 2019-05-13  Yusuke Suzuki  <ysuzuki@apple.com>
1834
1835         [WTF] Simplify GCThread and CompilationThread flags by adding them to WTF::Thread
1836         https://bugs.webkit.org/show_bug.cgi?id=197146
1837
1838         Reviewed by Saam Barati.
1839
1840         Rename Heap::Thread to Heap::HeapThread to remove conflict between WTF::Thread.
1841
1842         * heap/AlignedMemoryAllocator.cpp:
1843         (JSC::AlignedMemoryAllocator::registerDirectory):
1844         * heap/Heap.cpp:
1845         (JSC::Heap::HeapThread::HeapThread):
1846         (JSC::Heap::Heap):
1847         (JSC::Heap::runCurrentPhase):
1848         (JSC::Heap::runBeginPhase):
1849         (JSC::Heap::resumeThePeriphery):
1850         (JSC::Heap::requestCollection):
1851         (JSC::Heap::isCurrentThreadBusy):
1852         (JSC::Heap::notifyIsSafeToCollect):
1853         (JSC::Heap::Thread::Thread): Deleted.
1854         * heap/Heap.h:
1855         * heap/HeapInlines.h:
1856         (JSC::Heap::incrementDeferralDepth):
1857         (JSC::Heap::decrementDeferralDepth):
1858         (JSC::Heap::decrementDeferralDepthAndGCIfNeeded):
1859         * heap/MarkedSpace.cpp:
1860         (JSC::MarkedSpace::prepareForAllocation):
1861
1862 2019-05-13  Saam Barati  <sbarati@apple.com>
1863
1864         macro assembler code-pointer tagging has its arguments backwards
1865         https://bugs.webkit.org/show_bug.cgi?id=197677
1866
1867         Reviewed by Michael Saboff.
1868
1869         We had the destination as the leftmost instead of the rightmost argument,
1870         which goes against the convention of how we order arguments in macro assembler
1871         methods.
1872
1873         * assembler/MacroAssemblerARM64E.h:
1874         (JSC::MacroAssemblerARM64E::tagReturnAddress):
1875         (JSC::MacroAssemblerARM64E::untagReturnAddress):
1876         (JSC::MacroAssemblerARM64E::tagPtr):
1877         (JSC::MacroAssemblerARM64E::untagPtr):
1878         * dfg/DFGOSRExitCompilerCommon.cpp:
1879         (JSC::DFG::reifyInlinedCallFrames):
1880         * ftl/FTLThunks.cpp:
1881         (JSC::FTL::genericGenerationThunkGenerator):
1882         * jit/CCallHelpers.h:
1883         (JSC::CCallHelpers::prepareForTailCallSlow):
1884         * jit/CallFrameShuffler.cpp:
1885         (JSC::CallFrameShuffler::prepareForTailCall):
1886         * jit/ThunkGenerators.cpp:
1887         (JSC::emitPointerValidation):
1888         (JSC::arityFixupGenerator):
1889         * wasm/js/WebAssemblyFunction.cpp:
1890         (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
1891
1892 2019-05-13  Tadeu Zagallo  <tzagallo@apple.com>
1893
1894         JSObject::getOwnPropertyDescriptor is missing an exception check
1895         https://bugs.webkit.org/show_bug.cgi?id=197693
1896         <rdar://problem/50441784>
1897
1898         Reviewed by Saam Barati.
1899
1900         The method table call to getOwnPropertySlot might throw, and JSObject::getOwnPropertyDescriptor
1901         must handle the exception before calling PropertySlot::getValue, which can also throw.
1902
1903         * runtime/JSObject.cpp:
1904         (JSC::JSObject::getOwnPropertyDescriptor):
1905
1906 2019-05-13  Yusuke Suzuki  <ysuzuki@apple.com>
1907
1908         [JSC] Compress miscelaneous JIT related data structures with Packed<>
1909         https://bugs.webkit.org/show_bug.cgi?id=197830
1910
1911         Reviewed by Saam Barati.
1912
1913         This patch leverages Packed<> to compress miscelaneous data structures related to JIT.
1914
1915         1. JIT IC data structures
1916
1917         2. ValueRecovery
1918
1919             We use Packed<> for EncodedJSValue in ValueRecovery. This means that conservative GC cannot find
1920             these values. But this is OK anyway since ValueRecovery's constant should be already registered
1921             in DFG graph. From 16 (alignment 8) to 9 (alignment 1).
1922
1923         3. FTL::ExitValue
1924
1925             We use Packed<> for EncodedJSValue in FTL::ExitValue. This is also OK since this constant should
1926             be already registered by DFG/FTL graph. From 16 (alignment 8) to 9 (alignment 1).
1927
1928         * assembler/CodeLocation.h:
1929         * bytecode/ByValInfo.h:
1930         * bytecode/CallLinkInfo.cpp:
1931         (JSC::CallLinkInfo::CallLinkInfo):
1932         (JSC::CallLinkInfo::callReturnLocation):
1933         * bytecode/CallLinkInfo.h:
1934         (JSC::CallLinkInfo::nearCallMode const):
1935         * bytecode/CodeBlock.cpp:
1936         (JSC::CodeBlock::addJITAddIC):
1937         (JSC::CodeBlock::addJITMulIC):
1938         (JSC::CodeBlock::addJITSubIC):
1939         (JSC::CodeBlock::addJITNegIC):
1940         * bytecode/CodeBlock.h:
1941         (JSC::CodeBlock::addMathIC):
1942         * bytecode/InlineCallFrame.h:
1943         (JSC::InlineCallFrame::InlineCallFrame):
1944         * bytecode/ValueRecovery.h:
1945         (JSC::ValueRecovery::inGPR):
1946         (JSC::ValueRecovery::inPair):
1947         (JSC::ValueRecovery::inFPR):
1948         (JSC::ValueRecovery::displacedInJSStack):
1949         (JSC::ValueRecovery::constant):
1950         (JSC::ValueRecovery::directArgumentsThatWereNotCreated):
1951         (JSC::ValueRecovery::clonedArgumentsThatWereNotCreated):
1952         (JSC::ValueRecovery::gpr const):
1953         (JSC::ValueRecovery::tagGPR const):
1954         (JSC::ValueRecovery::payloadGPR const):
1955         (JSC::ValueRecovery::fpr const):
1956         (JSC::ValueRecovery::virtualRegister const):
1957         (JSC::ValueRecovery::withLocalsOffset const):
1958         (JSC::ValueRecovery::constant const):
1959         (JSC::ValueRecovery::nodeID const):
1960         * dfg/DFGSpeculativeJIT.cpp:
1961         (JSC::DFG::SpeculativeJIT::compileValueAdd):
1962         (JSC::DFG::SpeculativeJIT::compileValueSub):
1963         (JSC::DFG::SpeculativeJIT::compileValueNegate):
1964         (JSC::DFG::SpeculativeJIT::compileValueMul):
1965         * ftl/FTLExitValue.cpp:
1966         (JSC::FTL::ExitValue::materializeNewObject):
1967         * ftl/FTLExitValue.h:
1968         (JSC::FTL::ExitValue::inJSStack):
1969         (JSC::FTL::ExitValue::inJSStackAsInt32):
1970         (JSC::FTL::ExitValue::inJSStackAsInt52):
1971         (JSC::FTL::ExitValue::inJSStackAsDouble):
1972         (JSC::FTL::ExitValue::constant):
1973         (JSC::FTL::ExitValue::exitArgument):
1974         (JSC::FTL::ExitValue::exitArgument const):
1975         (JSC::FTL::ExitValue::adjustStackmapLocationsIndexByOffset):
1976         (JSC::FTL::ExitValue::constant const):
1977         (JSC::FTL::ExitValue::virtualRegister const):
1978         (JSC::FTL::ExitValue::objectMaterialization const):
1979         (JSC::FTL::ExitValue::withVirtualRegister const):
1980         * ftl/FTLLowerDFGToB3.cpp:
1981         (JSC::FTL::DFG::LowerDFGToB3::compileValueAdd):
1982         (JSC::FTL::DFG::LowerDFGToB3::compileValueSub):
1983         (JSC::FTL::DFG::LowerDFGToB3::compileValueMul):
1984         (JSC::FTL::DFG::LowerDFGToB3::compileUnaryMathIC):
1985         (JSC::FTL::DFG::LowerDFGToB3::compileBinaryMathIC):
1986         (JSC::FTL::DFG::LowerDFGToB3::compileArithAddOrSub):
1987         (JSC::FTL::DFG::LowerDFGToB3::compileValueNegate):
1988         * jit/CachedRecovery.h:
1989         * jit/CallFrameShuffleData.h:
1990         * jit/JITArithmetic.cpp:
1991         (JSC::JIT::emit_op_negate):
1992         (JSC::JIT::emit_op_add):
1993         (JSC::JIT::emit_op_mul):
1994         (JSC::JIT::emit_op_sub):
1995         * jit/JITMathIC.h:
1996         (JSC::isProfileEmpty):
1997         (JSC::JITBinaryMathIC::JITBinaryMathIC):
1998         (JSC::JITUnaryMathIC::JITUnaryMathIC):
1999         * jit/PolymorphicCallStubRoutine.h:
2000         (JSC::PolymorphicCallNode::hasCallLinkInfo):
2001         * jit/SnippetOperand.h:
2002         (JSC::SnippetOperand::asRawBits const):
2003         (JSC::SnippetOperand::asConstInt32 const):
2004         (JSC::SnippetOperand::asConstDouble const):
2005         (JSC::SnippetOperand::setConstInt32):
2006         (JSC::SnippetOperand::setConstDouble):
2007
2008 2019-05-12  Yusuke Suzuki  <ysuzuki@apple.com>
2009
2010         [JSC] Compress Watchpoint size by using enum type and Packed<> data structure
2011         https://bugs.webkit.org/show_bug.cgi?id=197730
2012
2013         Reviewed by Filip Pizlo.
2014
2015         Watchpoint takes 5~ MB memory in Gmail (total memory starts with 400 - 500 MB), so 1~%. Since it is allocated massively,
2016         reducing each size of Watchpoint reduces memory footprint significantly.
2017
2018         As a first step, this patch uses Packed<> and enum to reduce the size of Watchpoint.
2019
2020         1. Watchpoint should have enum type and should not use vtable. vtable takes one pointer, and it is too costly for such a
2021            memory sensitive objects. We perform downcast and dispatch the method of the derived classes based on this enum. Since
2022            the # of derived Watchpoint classes are limited (Only 8), we can list up them easily. One unfortunate thing is that
2023            we cannot do this for destructor so long as we use "delete" for deleting objects. If we dispatch the destructor of derived
2024            class in the destructor of the base class, we call the destructor of the base class multiple times. delete operator override
2025            does not help since custom delete operator is called after the destructor is called. While we can fix this issue by always
2026            using custom deleter, currently we do not since all the watchpoints do not have members which have non trivial destructor.
2027            Once it is strongly required, we can start using custom deleter, but for now, we do not need to do this.
2028
2029         2. We use Packed<> to compact pointers in Watchpoint. Since Watchpoint is a node of doubly linked list, each one has two
2030            pointers for prev and next. This is also too costly. PackedPtr reduces the size and makes alignment 1.S
2031
2032         3. We use PackedCellPtr<> for JSCells in Watchpoint. This leverages alignment information and makes pointers smaller in
2033            Darwin ARM64. One important thing to note here is that since this pointer is packed, it cannot be found by conservative
2034            GC scan. It is OK for watchpoint since they are allocated in the heap anyway.
2035
2036         We applied this change to Watchpoint and get the following memory reduction. The highlight is that CodeBlockJettisoningWatchpoint in
2037         ARM64 only takes 2 pointers size.
2038
2039                                                                               ORIGINAL    X86_64   ARM64
2040             WatchpointSet:                                                    40          32       28
2041             CodeBlockJettisoningWatchpoint:                                   32          19       15
2042             StructureStubClearingWatchpoint:                                  56          48       40
2043             AdaptiveInferredPropertyValueWatchpointBase::StructureWatchpoint: 24          13       11
2044             AdaptiveInferredPropertyValueWatchpointBase::PropertyWatchpoint:  24          13       11
2045             FunctionRareData::AllocationProfileClearingWatchpoint:            32          19       15
2046             ObjectToStringAdaptiveStructureWatchpoint:                        56          48       40
2047             LLIntPrototypeLoadAdaptiveStructureWatchpoint:                    64          48       48
2048             DFG::AdaptiveStructureWatchpoint:                                 56          48       40
2049
2050         While we will re-architect the mechanism of Watchpoint, anyway Packed<> mechanism and enum types will be used too.
2051
2052         * CMakeLists.txt:
2053         * JavaScriptCore.xcodeproj/project.pbxproj:
2054         * Sources.txt:
2055         * bytecode/AdaptiveInferredPropertyValueWatchpointBase.h:
2056         * bytecode/CodeBlockJettisoningWatchpoint.h:
2057         * bytecode/CodeOrigin.h:
2058         * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
2059         (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
2060         (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
2061         * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
2062         * bytecode/StructureStubClearingWatchpoint.cpp:
2063         (JSC::StructureStubClearingWatchpoint::fireInternal):
2064         * bytecode/StructureStubClearingWatchpoint.h:
2065         * bytecode/Watchpoint.cpp:
2066         (JSC::Watchpoint::fire):
2067         * bytecode/Watchpoint.h:
2068         (JSC::Watchpoint::Watchpoint):
2069         * dfg/DFGAdaptiveStructureWatchpoint.cpp:
2070         (JSC::DFG::AdaptiveStructureWatchpoint::AdaptiveStructureWatchpoint):
2071         * dfg/DFGAdaptiveStructureWatchpoint.h:
2072         * heap/PackedCellPtr.h: Added.
2073         * runtime/FunctionRareData.h:
2074         * runtime/ObjectToStringAdaptiveStructureWatchpoint.cpp: Added.
2075         (JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint):
2076         (JSC::ObjectToStringAdaptiveStructureWatchpoint::install):
2077         (JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal):
2078         * runtime/ObjectToStringAdaptiveStructureWatchpoint.h: Added.
2079         * runtime/StructureRareData.cpp:
2080         (JSC::StructureRareData::clearObjectToStringValue):
2081         (JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint): Deleted.
2082         (JSC::ObjectToStringAdaptiveStructureWatchpoint::install): Deleted.
2083         (JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal): Deleted.
2084         * runtime/StructureRareData.h:
2085
2086 2019-05-12  Yusuke Suzuki  <ysuzuki@apple.com>
2087
2088         [JSC] Compact generator code's bytecode size
2089         https://bugs.webkit.org/show_bug.cgi?id=197822
2090
2091         Reviewed by Michael Saboff.
2092
2093         op_put_to_scope's symbolTableOrScopeDepth is represented as int. This was OK for the old bytecode format since
2094         VirtualRegister / scope depth can be represented by int anyway. But it is problematic now since only int8_t range
2095         will be represented in narrow bytecode. When this field is used for symbol table constant index, it is always
2096         larger than FirstConstantRegisterIndex. So it always exceeds the range of int8_t, and results in wide bytecode.
2097         It makes all generator's op_put_to_scope wide bytecode.
2098
2099         In this patch, we introduce a new (logically) union type SymbolTableOrScopeDepth. It holds unsigned value, and we store the
2100         SymbolTableConstantIndex - FirstConstantRegisterIndex in this unsigned value to make op_put_to_scope narrow bytecode.
2101
2102         * CMakeLists.txt:
2103         * JavaScriptCore.xcodeproj/project.pbxproj:
2104         * bytecode/BytecodeGeneratorification.cpp:
2105         (JSC::BytecodeGeneratorification::run):
2106         * bytecode/BytecodeList.rb:
2107         * bytecode/CodeBlock.cpp:
2108         (JSC::CodeBlock::finishCreation):
2109         * bytecode/Fits.h:
2110         * bytecompiler/BytecodeGenerator.cpp:
2111         (JSC::BytecodeGenerator::BytecodeGenerator):
2112         (JSC::BytecodeGenerator::emitProfileType):
2113         (JSC::BytecodeGenerator::emitPutToScope):
2114         (JSC::BytecodeGenerator::localScopeDepth const):
2115         * bytecompiler/BytecodeGenerator.h:
2116         * runtime/SymbolTableOrScopeDepth.h: Added.
2117         (JSC::SymbolTableOrScopeDepth::symbolTable):
2118         (JSC::SymbolTableOrScopeDepth::scopeDepth):
2119         (JSC::SymbolTableOrScopeDepth::raw):
2120         (JSC::SymbolTableOrScopeDepth::symbolTable const):
2121         (JSC::SymbolTableOrScopeDepth::scopeDepth const):
2122         (JSC::SymbolTableOrScopeDepth::raw const):
2123         (JSC::SymbolTableOrScopeDepth::dump const):
2124         (JSC::SymbolTableOrScopeDepth::SymbolTableOrScopeDepth):
2125
2126 2019-05-10  Saam barati  <sbarati@apple.com>
2127
2128         Call to JSToWasmICCallee::createStructure passes in wrong prototype value
2129         https://bugs.webkit.org/show_bug.cgi?id=197807
2130         <rdar://problem/50530400>
2131
2132         Reviewed by Yusuke Suzuki.
2133
2134         We were passing the empty value instead of null. However, the empty
2135         value means the Structure is poly proto. That's definitely not the case
2136         here.
2137
2138         * runtime/JSGlobalObject.cpp:
2139         (JSC::JSGlobalObject::init):
2140
2141 2019-05-10  Yusuke Suzuki  <ysuzuki@apple.com>
2142
2143         [JSC] String substring operation should return ropes consistently
2144         https://bugs.webkit.org/show_bug.cgi?id=197765
2145         <rdar://problem/37689944>
2146
2147         Reviewed by Michael Saboff.
2148
2149         Currently we have different policies per string substring operation function.
2150
2151             1. String#slice returns the resolved non-rope string
2152             2. String#substring returns rope string
2153             3. String#substr returns rope string in runtime function, non-rope string in DFG and FTL
2154
2155         Due to (3), we see large memory use in the tested web page[1]. Non rope substring have a problem.
2156         First of all, that returned string seems not used immediately. It is possible that the resulted
2157         string is used as a part of the other ropes (like, xxx.substring(...) + "Hello"). To avoid the
2158         eager materialization of the string, we are using StringImpl::createSubstringSharingImpl for the
2159         resulted non rope string. StringImpl::createSubstringSharingImpl is StringImpl's substring feature: the
2160         substring is pointing the owner StringImpl. While this has memory saving benefit, it can retain owner
2161         StringImpl so long, and it could keep very large owner StringImpl alive.
2162
2163         The problem we are attempting to solve with StringImpl::createSubstringSharingImpl can be solved by
2164         the rope string simply. Rope string can share the underlying string. And good feature of the rope
2165         string is that, when resolving rope string, the rope string always create a new StringImpl instead of
2166         using StringImpl::createSubstringSharingImpl. So we allow the owner StringImpl to be destroyed. And this
2167         resolving only happens when we actually want to use the content of the rope string. In addition, we recently
2168         shrunk the sizeof(JSRopeString) from 48 to 32, so JSRopeString is cheap.
2169
2170         In this patch, we change (2) and (3) to (1), using rope String as a result of substring operations.
2171
2172         RAMification and JetStream2 are neutral. The web page[1] shows large memory footprint improvement from 776MB to 681MB.
2173
2174         [1]: https://beta.observablehq.com/@ldgardner/assignment-4-visualizations-and-multiple-views
2175
2176         * dfg/DFGOperations.cpp:
2177         * runtime/StringPrototype.cpp:
2178         (JSC::stringProtoFuncSlice):
2179         * runtime/StringPrototypeInlines.h:
2180         (JSC::stringSlice):
2181
2182 2019-05-10  Robin Morisset  <rmorisset@apple.com>
2183
2184         testb3 failing with crash in JSC::B3::BasicBlock::appendNonTerminal
2185         https://bugs.webkit.org/show_bug.cgi?id=197756
2186         <rdar://problem/50641659>
2187
2188         Reviewed by Saam Barati.
2189
2190         When I added https://bugs.webkit.org/show_bug.cgi?id=197265 I assumed that which block is the root does not change in the middle of strength reduction.
2191         But specializeSelect can use splitForward, which uses a new block for the first half of the given block.
2192         So if the block being split is the root block I must update m_root and erase the m_valueInConstant cache.
2193         Erasing the cache cannot cause wrong results: at most it can make us miss some optimization opportunities in this iteration of the fixpoint.
2194
2195         * b3/B3ReduceStrength.cpp:
2196
2197 2019-05-09  Keith Miller  <keith_miller@apple.com>
2198
2199         Fix crashes related to pointer authentication for primitive gigacage
2200         https://bugs.webkit.org/show_bug.cgi?id=197763
2201         <rdar://problem/50629257>
2202
2203         Reviewed by Saam Barati.
2204
2205         This fixes two bugs related to PAC for caging. The first is that
2206         we didn't clear the high bits of the size register going into the
2207         patchpoint to tag the new buffer for NewArrayBuffer. The second is
2208         that the GC needs to strip all stack pointers when considering
2209         them as a conservative root.
2210
2211         * ftl/FTLLowerDFGToB3.cpp:
2212         (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
2213         * heap/ConservativeRoots.cpp:
2214         (JSC::ConservativeRoots::genericAddPointer):
2215
2216 2019-05-09  Keith Miller  <keith_miller@apple.com>
2217
2218         parseStatementListItem needs a stack overflow check
2219         https://bugs.webkit.org/show_bug.cgi?id=197749
2220         <rdar://problem/50302697>
2221
2222         Reviewed by Saam Barati.
2223
2224         There currently exists a path in the parser where you can loop
2225         arbibrarily many times without a stack overflow check. This patch
2226         adds a check to parseStatementListItem to break that cycle.
2227
2228         * parser/Parser.cpp:
2229         (JSC::Parser<LexerType>::parseStatementListItem):
2230
2231 2019-05-09  Keith Miller  <keith_miller@apple.com>
2232
2233         REGRESSION (r245064): ASSERTION FAILED: m_ptr seen with wasm.yaml/wasm/js-api/test_Data.js.wasm-slow-memory
2234         https://bugs.webkit.org/show_bug.cgi?id=197740
2235
2236         Reviewed by Saam Barati.
2237
2238         If a TypedArray constructor is called with just 0 as the first argument, we don't allocate a backing vector.
2239         This means we need to handle null when calling vector() in ConstructionContext.
2240
2241         * runtime/JSArrayBufferView.h:
2242         (JSC::JSArrayBufferView::ConstructionContext::vector const):
2243
2244 2019-05-09  Xan L√≥pez  <xan@igalia.com>
2245
2246         [CMake] Detect SSE2 at compile time
2247         https://bugs.webkit.org/show_bug.cgi?id=196488
2248
2249         Reviewed by Carlos Garcia Campos.
2250
2251         * assembler/MacroAssemblerX86Common.cpp: Remove unnecessary (and
2252         incorrect) static_assert.
2253         (JSC::MacroAssemblerX86Common::collectCPUFeatures):
2254         * assembler/MacroAssemblerX86Common.h: Remove SSE2 flags.
2255
2256 2019-05-08  Yusuke Suzuki  <ysuzuki@apple.com>
2257
2258         Unreviewed, build fix after r245064
2259         https://bugs.webkit.org/show_bug.cgi?id=197110
2260
2261         * runtime/GenericTypedArrayView.h:
2262
2263 2019-05-08  Saam barati  <sbarati@apple.com>
2264
2265         AccessGenerationState::emitExplicitExceptionHandler can clobber an in use register
2266         https://bugs.webkit.org/show_bug.cgi?id=197715
2267         <rdar://problem/50399252>
2268
2269         Reviewed by Filip Pizlo.
2270
2271         AccessGenerationState::emitExplicitExceptionHandler was always clobbering
2272         x86's r9 without considering if that register was needed to be preserved
2273         by the IC. This leads to bad things when the DFG/FTL need that register when
2274         OSR exitting after an exception from a GetById call.
2275
2276         * b3/air/AirCode.cpp:
2277         (JSC::B3::Air::Code::Code):
2278         * bytecode/PolymorphicAccess.cpp:
2279         (JSC::AccessGenerationState::emitExplicitExceptionHandler):
2280         * runtime/Options.h:
2281
2282 2019-05-08  Ryan Haddad  <ryanhaddad@apple.com>
2283
2284         Unreviewed, rolling out r245068.
2285
2286         Caused debug layout tests to exit early due to an assertion
2287         failure.
2288
2289         Reverted changeset:
2290
2291         "All prototypes should call didBecomePrototype()"
2292         https://bugs.webkit.org/show_bug.cgi?id=196315
2293         https://trac.webkit.org/changeset/245068
2294
2295 2019-05-08  Yusuke Suzuki  <ysuzuki@apple.com>
2296
2297         Invalid DFG JIT genereation in high CPU usage state
2298         https://bugs.webkit.org/show_bug.cgi?id=197453
2299
2300         Reviewed by Saam Barati.
2301
2302         We have a DFG graph like this.
2303
2304             a: JSConstant(rope JSString)
2305             b: CheckStringIdent(Check:StringUse:@a)
2306             ... AI think this is unreachable ...
2307
2308         When executing StringUse edge filter onto @a, AbstractValue::filterValueByType clears AbstractValue and makes it None.
2309         This is because @a constant produces SpecString (SpecStringVar | SpecStringIdent) while StringUse edge filter requires
2310         SpecStringIdent. AbstractValue::filterValueByType has an assumption that the JS constant always produces the same
2311         SpeculatedType. So it clears AbstractValue completely.
2312         But this assumption is wrong. JSString can produce SpecStringIdent later if the string is resolved to AtomicStringImpl.
2313         AI think that we always fail. But once the string is resolved to AtomicStringImpl, we pass this check. So we execute
2314         the breakpoint emitted by DFG since DFG think this is unreachable.
2315
2316         In this patch, we just clear the `m_value` if AbstractValue type filter fails with the held constant, since the constant
2317         may produce a narrower type which can meet the type filter later.
2318
2319         * dfg/DFGAbstractValue.cpp:
2320         (JSC::DFG::AbstractValue::filterValueByType):
2321
2322 2019-05-08  Robin Morisset  <rmorisset@apple.com>
2323
2324         All prototypes should call didBecomePrototype()
2325         https://bugs.webkit.org/show_bug.cgi?id=196315
2326
2327         Reviewed by Saam Barati.
2328
2329         This changelog already landed, but the commit was missing the actual changes.
2330
2331         Otherwise we won't remember to run haveABadTime() when someone adds to them an indexed accessor.
2332
2333         I added a check used in both Structure::finishCreation() and Structure::changePrototypeTransition to make sure we don't
2334         create structures with invalid prototypes.
2335         It found a lot of objects that are used as prototypes in JSGlobalObject and yet were missing didBecomePrototype() in their finishCreation().
2336         Somewhat surprisingly, some of them have names like FunctionConstructor and not only FooPrototype.
2337
2338         * runtime/BigIntPrototype.cpp:
2339         (JSC::BigIntPrototype::finishCreation):
2340         * runtime/BooleanPrototype.cpp:
2341         (JSC::BooleanPrototype::finishCreation):
2342         * runtime/DatePrototype.cpp:
2343         (JSC::DatePrototype::finishCreation):
2344         * runtime/ErrorConstructor.cpp:
2345         (JSC::ErrorConstructor::finishCreation):
2346         * runtime/ErrorPrototype.cpp:
2347         (JSC::ErrorPrototype::finishCreation):
2348         * runtime/FunctionConstructor.cpp:
2349         (JSC::FunctionConstructor::finishCreation):
2350         * runtime/FunctionPrototype.cpp:
2351         (JSC::FunctionPrototype::finishCreation):
2352         * runtime/IntlCollatorPrototype.cpp:
2353         (JSC::IntlCollatorPrototype::finishCreation):
2354         * runtime/IntlDateTimeFormatPrototype.cpp:
2355         (JSC::IntlDateTimeFormatPrototype::finishCreation):
2356         * runtime/IntlNumberFormatPrototype.cpp:
2357         (JSC::IntlNumberFormatPrototype::finishCreation):
2358         * runtime/IntlPluralRulesPrototype.cpp:
2359         (JSC::IntlPluralRulesPrototype::finishCreation):
2360         * runtime/JSArrayBufferPrototype.cpp:
2361         (JSC::JSArrayBufferPrototype::finishCreation):
2362         * runtime/JSDataViewPrototype.cpp:
2363         (JSC::JSDataViewPrototype::finishCreation):
2364         * runtime/JSGenericTypedArrayViewPrototypeInlines.h:
2365         (JSC::JSGenericTypedArrayViewPrototype<ViewClass>::finishCreation):
2366         * runtime/JSGlobalObject.cpp:
2367         (JSC::createConsoleProperty):
2368         * runtime/JSPromisePrototype.cpp:
2369         (JSC::JSPromisePrototype::finishCreation):
2370         * runtime/JSTypedArrayViewConstructor.cpp:
2371         (JSC::JSTypedArrayViewConstructor::finishCreation):
2372         * runtime/JSTypedArrayViewPrototype.cpp:
2373         (JSC::JSTypedArrayViewPrototype::finishCreation):
2374         * runtime/NumberPrototype.cpp:
2375         (JSC::NumberPrototype::finishCreation):
2376         * runtime/RegExpPrototype.cpp:
2377         (JSC::RegExpPrototype::finishCreation):
2378         * runtime/StringPrototype.cpp:
2379         (JSC::StringPrototype::finishCreation):
2380         * runtime/Structure.cpp:
2381         (JSC::Structure::isValidPrototype):
2382         (JSC::Structure::changePrototypeTransition):
2383         * runtime/Structure.h:
2384         * runtime/SymbolPrototype.cpp:
2385         (JSC::SymbolPrototype::finishCreation):
2386         * wasm/js/WebAssemblyCompileErrorPrototype.cpp:
2387         (JSC::WebAssemblyCompileErrorPrototype::finishCreation):
2388         * wasm/js/WebAssemblyInstancePrototype.cpp:
2389         (JSC::WebAssemblyInstancePrototype::finishCreation):
2390         * wasm/js/WebAssemblyLinkErrorPrototype.cpp:
2391         (JSC::WebAssemblyLinkErrorPrototype::finishCreation):
2392         * wasm/js/WebAssemblyMemoryPrototype.cpp:
2393         (JSC::WebAssemblyMemoryPrototype::finishCreation):
2394         * wasm/js/WebAssemblyModulePrototype.cpp:
2395         (JSC::WebAssemblyModulePrototype::finishCreation):
2396         * wasm/js/WebAssemblyPrototype.cpp:
2397         (JSC::WebAssemblyPrototype::finishCreation):
2398         * wasm/js/WebAssemblyRuntimeErrorPrototype.cpp:
2399         (JSC::WebAssemblyRuntimeErrorPrototype::finishCreation):
2400         * wasm/js/WebAssemblyTablePrototype.cpp:
2401         (JSC::WebAssemblyTablePrototype::finishCreation):
2402
2403 2019-05-08  Keith Miller  <keith_miller@apple.com>
2404
2405         Remove Gigacage from arm64 and use PAC for arm64e instead
2406         https://bugs.webkit.org/show_bug.cgi?id=197110
2407
2408         Reviewed by Saam Barati.
2409
2410         This patch makes a bunch of changes. I'll start with global changes then go over changes to each tier and finish with bug fixes.
2411
2412         Global Changes:
2413         Change CagedBarrierPtr to work with PAC so constructors and accessors now expect to receive a length.
2414         Update assembler helper methods to use do PAC when caging.
2415
2416         LLInt:
2417         Add arm64e.rb backend as we missed that when originally open sourcing our arm64e code.
2418         Add a new optional t6 temporary, which is only used currently on arm64e for GetByVal on a TypedArray.
2419         Refactor caging into two helper macros for Primitive/JSValue cages.
2420
2421         Baseline/DFG:
2422         Add authentication where needed for GetByVal and inline object construction.
2423
2424         FTL:
2425         Add a new ValueRep that allows for a late register use. We want this for the authentication patchpoint since we use the length register at the same time as we are defing the authenticated pointer.
2426
2427         Wasm:
2428         Use the TaggedArrayStoragePtr class for the memory base pointer. In theory we should be caging those pointers but I don't want to risk introducing a performance regression with the rest of this change. I've filed https://bugs.webkit.org/show_bug.cgi?id=197620 to do this later.
2429         As we no longer have the Gigacage using most of our VA memory, we can enable fast memories on iOS.
2430         Using fast memories leads to roughly a 2% JetStream2 speedup.
2431
2432         * assembler/MacroAssemblerARM64E.h:
2433         (JSC::MacroAssemblerARM64E::tagArrayPtr):
2434         (JSC::MacroAssemblerARM64E::untagArrayPtr):
2435         (JSC::MacroAssemblerARM64E::removeArrayPtrTag):
2436         * b3/B3LowerToAir.cpp:
2437         * b3/B3PatchpointSpecial.cpp:
2438         (JSC::B3::PatchpointSpecial::admitsStack):
2439         * b3/B3StackmapSpecial.cpp:
2440         (JSC::B3::StackmapSpecial::forEachArgImpl):
2441         (JSC::B3::StackmapSpecial::isArgValidForRep):
2442         * b3/B3Validate.cpp:
2443         * b3/B3ValueRep.cpp:
2444         (JSC::B3::ValueRep::addUsedRegistersTo const):
2445         (JSC::B3::ValueRep::dump const):
2446         (WTF::printInternal):
2447         * b3/B3ValueRep.h:
2448         (JSC::B3::ValueRep::ValueRep):
2449         (JSC::B3::ValueRep::isReg const):
2450         * dfg/DFGOperations.cpp:
2451         (JSC::DFG::newTypedArrayWithSize):
2452         * dfg/DFGSpeculativeJIT.cpp:
2453         (JSC::DFG::SpeculativeJIT::jumpForTypedArrayIsNeuteredIfOutOfBounds):
2454         (JSC::DFG::SpeculativeJIT::cageTypedArrayStorage):
2455         (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
2456         (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
2457         (JSC::DFG::SpeculativeJIT::compileNewTypedArrayWithSize):
2458         * dfg/DFGSpeculativeJIT.h:
2459         * dfg/DFGSpeculativeJIT64.cpp:
2460         (JSC::DFG::SpeculativeJIT::compile):
2461         * ftl/FTLLowerDFGToB3.cpp:
2462         (JSC::FTL::DFG::LowerDFGToB3::compileGetIndexedPropertyStorage):
2463         (JSC::FTL::DFG::LowerDFGToB3::compileGetTypedArrayByteOffset):
2464         (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
2465         (JSC::FTL::DFG::LowerDFGToB3::compileDataViewGet):
2466         (JSC::FTL::DFG::LowerDFGToB3::compileDataViewSet):
2467         (JSC::FTL::DFG::LowerDFGToB3::untagArrayPtr):
2468         (JSC::FTL::DFG::LowerDFGToB3::caged):
2469         (JSC::FTL::DFG::LowerDFGToB3::speculateTypedArrayIsNotNeutered):
2470         * jit/AssemblyHelpers.h:
2471         (JSC::AssemblyHelpers::cageConditionally):
2472         * jit/IntrinsicEmitter.cpp:
2473         (JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter):
2474         * jit/JITPropertyAccess.cpp:
2475         (JSC::JIT::emitDirectArgumentsGetByVal):
2476         (JSC::JIT::emitIntTypedArrayGetByVal):
2477         (JSC::JIT::emitFloatTypedArrayGetByVal):
2478         (JSC::JIT::emitIntTypedArrayPutByVal):
2479         (JSC::JIT::emitFloatTypedArrayPutByVal):
2480         * jit/PolymorphicCallStubRoutine.cpp:
2481         (JSC::PolymorphicCallNode::clearCallLinkInfo):
2482         * llint/LowLevelInterpreter64.asm:
2483         * offlineasm/arm64.rb:
2484         * offlineasm/arm64e.rb: Added.
2485         * offlineasm/ast.rb:
2486         * offlineasm/instructions.rb:
2487         * offlineasm/registers.rb:
2488         * offlineasm/x86.rb:
2489         * runtime/ArrayBuffer.cpp:
2490         (JSC::SharedArrayBufferContents::SharedArrayBufferContents):
2491         (JSC::SharedArrayBufferContents::~SharedArrayBufferContents):
2492         (JSC::ArrayBufferContents::ArrayBufferContents):
2493         (JSC::ArrayBufferContents::destroy):
2494         (JSC::ArrayBufferContents::tryAllocate):
2495         (JSC::ArrayBufferContents::makeShared):
2496         (JSC::ArrayBufferContents::copyTo):
2497         * runtime/ArrayBuffer.h:
2498         (JSC::SharedArrayBufferContents::data const):
2499         (JSC::ArrayBufferContents::data const):
2500         (JSC::ArrayBuffer::data):
2501         (JSC::ArrayBuffer::data const):
2502         (JSC::ArrayBuffer::byteLength const):
2503         * runtime/ArrayBufferView.cpp:
2504         (JSC::ArrayBufferView::ArrayBufferView):
2505         * runtime/ArrayBufferView.h:
2506         (JSC::ArrayBufferView::baseAddress const):
2507         (JSC::ArrayBufferView::byteLength const):
2508         (JSC::ArrayBufferView::setRangeImpl):
2509         (JSC::ArrayBufferView::getRangeImpl):
2510         * runtime/CachedTypes.cpp:
2511         (JSC::CachedScopedArgumentsTable::encode):
2512         (JSC::CachedScopedArgumentsTable::decode const):
2513         * runtime/CagedBarrierPtr.h:
2514         (JSC::CagedBarrierPtr::CagedBarrierPtr):
2515         (JSC::CagedBarrierPtr::set):
2516         (JSC::CagedBarrierPtr::get const):
2517         (JSC::CagedBarrierPtr::getMayBeNull const):
2518         (JSC::CagedBarrierPtr::getUnsafe const):
2519         (JSC::CagedBarrierPtr::at const):
2520         (JSC::CagedBarrierPtr::operator== const):
2521         (JSC::CagedBarrierPtr::operator bool const):
2522         (JSC::CagedBarrierPtr::setWithoutBarrier):
2523         (JSC::CagedBarrierPtr::operator* const): Deleted.
2524         (JSC::CagedBarrierPtr::operator-> const): Deleted.
2525         (JSC::CagedBarrierPtr::operator[] const): Deleted.
2526         (): Deleted.
2527         * runtime/DataView.cpp:
2528         (JSC::DataView::DataView):
2529         * runtime/DataView.h:
2530         (JSC::DataView::get):
2531         (JSC::DataView::set):
2532         * runtime/DirectArguments.cpp:
2533         (JSC::DirectArguments::visitChildren):
2534         (JSC::DirectArguments::overrideThings):
2535         (JSC::DirectArguments::unmapArgument):
2536         * runtime/DirectArguments.h:
2537         * runtime/GenericArguments.h:
2538         * runtime/GenericArgumentsInlines.h:
2539         (JSC::GenericArguments<Type>::visitChildren):
2540         (JSC::GenericArguments<Type>::initModifiedArgumentsDescriptor):
2541         (JSC::GenericArguments<Type>::setModifiedArgumentDescriptor):
2542         (JSC::GenericArguments<Type>::isModifiedArgumentDescriptor):
2543         * runtime/GenericTypedArrayView.h:
2544         * runtime/GenericTypedArrayViewInlines.h:
2545         (JSC::GenericTypedArrayView<Adaptor>::GenericTypedArrayView):
2546         * runtime/JSArrayBufferView.cpp:
2547         (JSC::JSArrayBufferView::ConstructionContext::ConstructionContext):
2548         (JSC::JSArrayBufferView::JSArrayBufferView):
2549         (JSC::JSArrayBufferView::finalize):
2550         (JSC::JSArrayBufferView::slowDownAndWasteMemory):
2551         * runtime/JSArrayBufferView.h:
2552         (JSC::JSArrayBufferView::ConstructionContext::vector const):
2553         (JSC::JSArrayBufferView::isNeutered):
2554         (JSC::JSArrayBufferView::hasVector const):
2555         (JSC::JSArrayBufferView::vector const):
2556         * runtime/JSGenericTypedArrayViewInlines.h:
2557         (JSC::JSGenericTypedArrayView<Adaptor>::createUninitialized):
2558         (JSC::JSGenericTypedArrayView<Adaptor>::estimatedSize):
2559         (JSC::JSGenericTypedArrayView<Adaptor>::visitChildren):
2560         * runtime/Options.h:
2561         * runtime/ScopedArgumentsTable.cpp:
2562         (JSC::ScopedArgumentsTable::clone):
2563         (JSC::ScopedArgumentsTable::setLength):
2564         * runtime/ScopedArgumentsTable.h:
2565         * runtime/SymbolTable.h:
2566         * wasm/WasmAirIRGenerator.cpp:
2567         (JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState):
2568         (JSC::Wasm::AirIRGenerator::addCallIndirect):
2569         * wasm/WasmB3IRGenerator.cpp:
2570         (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
2571         (JSC::Wasm::B3IRGenerator::addCallIndirect):
2572         * wasm/WasmBBQPlan.cpp:
2573         (JSC::Wasm::BBQPlan::complete):
2574         * wasm/WasmBinding.cpp:
2575         (JSC::Wasm::wasmToWasm):
2576         * wasm/WasmInstance.h:
2577         (JSC::Wasm::Instance::cachedMemory const):
2578         (JSC::Wasm::Instance::updateCachedMemory):
2579         * wasm/WasmMemory.cpp:
2580         (JSC::Wasm::Memory::Memory):
2581         (JSC::Wasm::Memory::~Memory):
2582         (JSC::Wasm::Memory::grow):
2583         (JSC::Wasm::Memory::dump const):
2584         * wasm/WasmMemory.h:
2585         (JSC::Wasm::Memory::memory const):
2586         * wasm/js/JSToWasm.cpp:
2587         (JSC::Wasm::createJSToWasmWrapper):
2588         * wasm/js/WebAssemblyFunction.cpp:
2589         (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
2590
2591 2019-05-08  Caio Lima  <ticaiolima@gmail.com>
2592
2593         [BigInt] Add ValueMod into DFG
2594         https://bugs.webkit.org/show_bug.cgi?id=186174
2595
2596         Reviewed by Saam Barati.
2597
2598         This patch is introducing a new DFG node called ValueMod, that is
2599         responsible to handle BigInt and Untyped specialization of op_mod.
2600         With the introduction of BigInt, we think that cases with
2601         ValueMod(Untyped, Untyped) can be more common and we introduced
2602         support for such kind of node.
2603
2604         * dfg/DFGAbstractInterpreter.h:
2605         * dfg/DFGAbstractInterpreterInlines.h:
2606         (JSC::DFG::AbstractInterpreter<AbstractStateType>::handleConstantDivOp):
2607
2608         We are abstracting the constant rules of division operations. It
2609         includes ArithDiv, ValueDiv, ArithMod and ValueMod, since they perform
2610         the same analysis.
2611
2612         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2613         * dfg/DFGBackwardsPropagationPhase.cpp:
2614         (JSC::DFG::BackwardsPropagationPhase::propagate):
2615         * dfg/DFGByteCodeParser.cpp:
2616         (JSC::DFG::ByteCodeParser::makeSafe):
2617         (JSC::DFG::ByteCodeParser::parseBlock):
2618
2619         Here we check if lhs and rhs have number result to emit ArithMod.
2620         Otherwise, we need to fallback to ValueMod and let fixup replace this
2621         operation when possible.
2622
2623         * dfg/DFGClobberize.h:
2624         (JSC::DFG::clobberize):
2625
2626         ValueMod(BigIntUse) doesn't clobberize world because it only calls
2627         `operationModBigInt`.
2628
2629         * dfg/DFGDoesGC.cpp:
2630         (JSC::DFG::doesGC):
2631
2632         ValueMod(BigIntUse) can trigger GC since it allocates intermediate
2633         JSBigInt to perform calculation. ValueMod(UntypedUse) can trigger GC
2634         because it can execute arbritary code from user.
2635
2636         * dfg/DFGFixupPhase.cpp:
2637         (JSC::DFG::FixupPhase::fixupArithDivInt32):
2638
2639         Function created to simplify readability of ArithDiv/AirthMod fixup
2640         operation.
2641
2642         (JSC::DFG::FixupPhase::fixupArithDiv):
2643         (JSC::DFG::FixupPhase::fixupNode):
2644
2645         Following the same fixup rules of ArithDiv.
2646
2647         * dfg/DFGNodeType.h:
2648         * dfg/DFGOperations.cpp:
2649         (JSC::DFG::binaryOp):
2650         * dfg/DFGOperations.h:
2651         * dfg/DFGPredictionPropagationPhase.cpp:
2652
2653         ValueMod follows the same prediction propagation rules of ArithMod and
2654         the same rules for `doDoubleVoting`.
2655
2656         * dfg/DFGSafeToExecute.h:
2657         (JSC::DFG::safeToExecute):
2658         * dfg/DFGSpeculativeJIT.cpp:
2659         (JSC::DFG::SpeculativeJIT::compileValueMod):
2660         * dfg/DFGSpeculativeJIT.h:
2661         * dfg/DFGSpeculativeJIT32_64.cpp:
2662         (JSC::DFG::SpeculativeJIT::compile):
2663         * dfg/DFGSpeculativeJIT64.cpp:
2664         (JSC::DFG::SpeculativeJIT::compile):
2665         * dfg/DFGValidate.cpp:
2666         * ftl/FTLCapabilities.cpp:
2667         (JSC::FTL::canCompile):
2668         * ftl/FTLLowerDFGToB3.cpp:
2669         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2670         (JSC::FTL::DFG::LowerDFGToB3::compileValueMod):
2671
2672 2019-05-07  Yusuke Suzuki  <ysuzuki@apple.com>
2673
2674         [JSC] DFG_ASSERT failed in lowInt52
2675         https://bugs.webkit.org/show_bug.cgi?id=197569
2676
2677         Reviewed by Saam Barati.
2678
2679         GetStack with FlushedInt52 should load the flushed value in Int52 form and put the result in m_int52Values / m_strictInt52Values. Previously,
2680         we load it in JSValue / Int32 form and lowInt52 fails to get appropriate one since GetStack does not put the result in m_int52Values / m_strictInt52Values.
2681
2682         * ftl/FTLLowerDFGToB3.cpp:
2683         (JSC::FTL::DFG::LowerDFGToB3::compileGetStack):
2684
2685 2019-05-07  Yusuke Suzuki  <ysuzuki@apple.com>
2686
2687         [JSC] LLIntPrototypeLoadAdaptiveStructureWatchpoint does not require Bag<>
2688         https://bugs.webkit.org/show_bug.cgi?id=197645
2689
2690         Reviewed by Saam Barati.
2691
2692         We are using HashMap<std::tuple<Structure*, const Instruction*>, Bag<LLIntPrototypeLoadAdaptiveStructureWatchpoint>> for LLIntPrototypeLoadAdaptiveStructureWatchpoint,
2693         but this has several memory inefficiency.
2694
2695         1. Structure* and Instruction* are too large. We can just use StructureID and bytecodeOffset (unsigned).
2696         2. While we are using Bag<>, we do not add a new LLIntPrototypeLoadAdaptiveStructureWatchpoint after constructing this Bag first. So we can
2697            use Vector<LLIntPrototypeLoadAdaptiveStructureWatchpoint> instead. We ensure that new entry won't be added to this Vector by making Watchpoint
2698            non-movable.
2699         3. Instead of having OpGetById::Metadata&, we just hold `unsigned` bytecodeOffset, and get Metadata& from the owner CodeBlock when needed.
2700
2701         * bytecode/CodeBlock.cpp:
2702         (JSC::CodeBlock::finalizeLLIntInlineCaches):
2703         * bytecode/CodeBlock.h:
2704         * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
2705         (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
2706         (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
2707         * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
2708         * bytecode/Watchpoint.h:
2709         * llint/LLIntSlowPaths.cpp:
2710         (JSC::LLInt::setupGetByIdPrototypeCache):
2711
2712 2019-05-07  Yusuke Suzuki  <ysuzuki@apple.com>
2713
2714         JSC: A bug in BytecodeGenerator::emitEqualityOpImpl
2715         https://bugs.webkit.org/show_bug.cgi?id=197479
2716
2717         Reviewed by Saam Barati.
2718
2719         Our peephole optimization in BytecodeGenerator is (1) rewinding the previous instruction and (2) emit optimized instruction instead.
2720         If we have jump target between the previous instruction and the subsequent instruction, this peephole optimization breaks the jump target.
2721         To prevent it, we had a mechanism disabling peephole optimization, setting m_lastOpcodeID = op_end and checking m_lastOpcodeID when performing
2722         peephole optimization. However, BytecodeGenerator::emitEqualityOpImpl checks `m_lastInstruction->is<OpTypeof>` instead of `m_lastOpcodeID == op_typeof`,
2723         and miss `op_end` case.
2724
2725         This patch makes the following changes.
2726
2727         1. Add canDoPeepholeOptimization method to clarify the intent of `m_lastInstruction = op_end`.
2728         2. Check canDoPeepholeOptimization status before performing peephole optimization in emitJumpIfTrue, emitJumpIfFalse, and emitEqualityOpImpl.
2729         3. Add `ASSERT(canDoPeepholeOptimization())` in fuseCompareAndJump and fuseTestAndJmp to ensure that peephole optimization is allowed.
2730
2731         * bytecompiler/BytecodeGenerator.cpp:
2732         (JSC::BytecodeGenerator::fuseCompareAndJump):
2733         (JSC::BytecodeGenerator::fuseTestAndJmp):
2734         (JSC::BytecodeGenerator::emitJumpIfTrue):
2735         (JSC::BytecodeGenerator::emitJumpIfFalse):
2736         (JSC::BytecodeGenerator::emitEqualityOpImpl):
2737         * bytecompiler/BytecodeGenerator.h:
2738         (JSC::BytecodeGenerator::canDoPeepholeOptimization const):
2739
2740 2019-05-07  Yusuke Suzuki  <ysuzuki@apple.com>
2741
2742         TemplateObject passed to template literal tags are not always identical for the same source location.
2743         https://bugs.webkit.org/show_bug.cgi?id=190756
2744
2745         Reviewed by Saam Barati.
2746
2747         Tagged template literal requires that the site object is allocated per source location. Previously, we create the site object
2748         when linking CodeBlock and cache it in CodeBlock. But this is wrong because,
2749
2750         1. CodeBlock can be jettisoned and regenerated. So every time CodeBlock is regenerated, we get the different site object.
2751         2. Call and Construct can have different CodeBlock. Even if the function is called in call-form or construct-form, we should return the same site object.
2752
2753         In this patch, we start caching these site objects in the top-level ScriptExecutable, this matches the spec's per source location since the only one top-level
2754         ScriptExecutable is created for the given script code. Each ScriptExecutable of JSFunction can be created multiple times because CodeBlock creates it.
2755         But the top-level one is not created by CodeBlock. This top-level ScriptExecutable is well-aligned to the Script itself. The top-level ScriptExecutable now has HashMap,
2756         which maps source locations to cached site objects.
2757
2758         1. This patch threads the top-level ScriptExecutable to each FunctionExecutable creation. Each FunctionExecutable has a reference to the top-level ScriptExecutable.
2759         2. We put TemplateObjectMap in ScriptExecutable, which manages cached template objects.
2760         3. We move FunctionExecutable::m_cachedPolyProtoStructure to the FunctionExecutable::RareDate to keep FunctionExecutable 128 bytes.
2761         4. TemplateObjectMap is indexed with endOffset of TaggedTemplate.
2762
2763         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
2764         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
2765         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
2766         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result:
2767         * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
2768         * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result:
2769         * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result:
2770         * Scripts/tests/builtins/expected/WebCore-AnotherGuardedInternalBuiltin-Separate.js-result:
2771         * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
2772         * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
2773         * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
2774         * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
2775         * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
2776         * Scripts/wkbuiltins/builtins_templates.py:
2777         * bytecode/CodeBlock.cpp:
2778         (JSC::CodeBlock::finishCreation):
2779         (JSC::CodeBlock::setConstantRegisters):
2780         * bytecode/CodeBlock.h:
2781         * bytecode/UnlinkedFunctionExecutable.cpp:
2782         (JSC::UnlinkedFunctionExecutable::link):
2783         * bytecode/UnlinkedFunctionExecutable.h:
2784         * bytecompiler/BytecodeGenerator.cpp:
2785         (JSC::BytecodeGenerator::addTemplateObjectConstant):
2786         (JSC::BytecodeGenerator::emitGetTemplateObject):
2787         * bytecompiler/BytecodeGenerator.h:
2788         * parser/ASTBuilder.h:
2789         (JSC::ASTBuilder::createTaggedTemplate):
2790         * runtime/CachedTypes.cpp:
2791         (JSC::CachedTemplateObjectDescriptor::encode):
2792         (JSC::CachedTemplateObjectDescriptor::decode const):
2793         (JSC::CachedJSValue::encode):
2794         (JSC::CachedJSValue::decode const):
2795         * runtime/EvalExecutable.cpp:
2796         (JSC::EvalExecutable::ensureTemplateObjectMap):
2797         (JSC::EvalExecutable::visitChildren):
2798         * runtime/EvalExecutable.h:
2799         * runtime/FunctionExecutable.cpp:
2800         (JSC::FunctionExecutable::finishCreation):
2801         (JSC::FunctionExecutable::visitChildren):
2802         (JSC::FunctionExecutable::fromGlobalCode):
2803         (JSC::FunctionExecutable::ensureRareDataSlow):
2804         (JSC::FunctionExecutable::ensureTemplateObjectMap):
2805         * runtime/FunctionExecutable.h:
2806         * runtime/JSModuleRecord.cpp:
2807         (JSC::JSModuleRecord::instantiateDeclarations):
2808         * runtime/JSTemplateObjectDescriptor.cpp:
2809         (JSC::JSTemplateObjectDescriptor::JSTemplateObjectDescriptor):
2810         (JSC::JSTemplateObjectDescriptor::create):
2811         * runtime/JSTemplateObjectDescriptor.h:
2812         * runtime/ModuleProgramExecutable.cpp:
2813         (JSC::ModuleProgramExecutable::ensureTemplateObjectMap):
2814         (JSC::ModuleProgramExecutable::visitChildren):
2815         * runtime/ModuleProgramExecutable.h:
2816         * runtime/ProgramExecutable.cpp:
2817         (JSC::ProgramExecutable::ensureTemplateObjectMap):
2818         (JSC::ProgramExecutable::visitChildren):
2819         * runtime/ProgramExecutable.h:
2820         * runtime/ScriptExecutable.cpp:
2821         (JSC::ScriptExecutable::topLevelExecutable):
2822         (JSC::ScriptExecutable::createTemplateObject):
2823         (JSC::ScriptExecutable::ensureTemplateObjectMapImpl):
2824         (JSC::ScriptExecutable::ensureTemplateObjectMap):
2825         * runtime/ScriptExecutable.h:
2826         * tools/JSDollarVM.cpp:
2827         (JSC::functionCreateBuiltin):
2828         (JSC::functionDeleteAllCodeWhenIdle):
2829         (JSC::JSDollarVM::finishCreation):
2830
2831 2019-05-07  Robin Morisset  <rmorisset@apple.com>
2832
2833         [B3] Constants should be hoisted to the root block until moveConstants
2834         https://bugs.webkit.org/show_bug.cgi?id=197265
2835
2836         Reviewed by Saam Barati.
2837
2838         This patch does the following:
2839         - B3ReduceStrength now hoists all constants to the root BB, and de-duplicates them along the way
2840         - B3PureCSE no longer bothers with constants, since they are already de-duplicated by the time it gets to see them
2841         - We now run eliminateDeadCode just after moveConstants, so that the Nops that moveConstants generates are freed instead of staying live throughout Air compilation, reducing memory pressure.
2842         - I also took the opportunity to fix typos in comments in various parts of the code base.
2843
2844         Here are a few numbers to justify this patch:
2845         - In JetStream2, about 27% of values at the beginning of B3 are constants
2846         - In JetStream2, about 11% of values at the end of B3 are Nops
2847         - In JetStream2, this patch increases the number of times that tail duplication happens from a bit less than 24k to a bit more than 25k (hoisting constants makes blocks smaller).
2848
2849         When I tried measuring the total effect on JetStream2 I got a tiny and almost certainly non-significant progression.
2850
2851         * b3/B3Generate.cpp:
2852         (JSC::B3::generateToAir):
2853         * b3/B3MoveConstants.cpp:
2854         * b3/B3PureCSE.cpp:
2855         (JSC::B3::PureCSE::process):
2856         * b3/B3PureCSE.h:
2857         * b3/B3ReduceStrength.cpp:
2858         * bytecode/GetByIdStatus.cpp:
2859         (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
2860         * dfg/DFGCSEPhase.cpp:
2861         * dfg/DFGOSRAvailabilityAnalysisPhase.h:
2862         * dfg/DFGOSRExit.cpp:
2863         (JSC::DFG::OSRExit::executeOSRExit):
2864
2865 2019-05-07  Robin Morisset  <rmorisset@apple.com>
2866
2867         All prototypes should call didBecomePrototype()
2868         https://bugs.webkit.org/show_bug.cgi?id=196315
2869
2870         Reviewed by Saam Barati.
2871
2872         Otherwise we won't remember to run haveABadTime() when someone adds to them an indexed accessor.
2873
2874         I added a check used in both Structure::finishCreation() and Structure::changePrototypeTransition to make sure we don't
2875         create structures with invalid prototypes.
2876         It found a lot of objects that are used as prototypes in JSGlobalObject and yet were missing didBecomePrototype() in their finishCreation().
2877         Somewhat surprisingly, some of them have names like FunctionConstructor and not only FooPrototype.
2878
2879         * runtime/BigIntPrototype.cpp:
2880         (JSC::BigIntPrototype::finishCreation):
2881         * runtime/BooleanPrototype.cpp:
2882         (JSC::BooleanPrototype::finishCreation):
2883         * runtime/DatePrototype.cpp:
2884         (JSC::DatePrototype::finishCreation):
2885         * runtime/ErrorConstructor.cpp:
2886         (JSC::ErrorConstructor::finishCreation):
2887         * runtime/ErrorPrototype.cpp:
2888         (JSC::ErrorPrototype::finishCreation):
2889         * runtime/FunctionConstructor.cpp:
2890         (JSC::FunctionConstructor::finishCreation):
2891         * runtime/FunctionPrototype.cpp:
2892         (JSC::FunctionPrototype::finishCreation):
2893         * runtime/IntlCollatorPrototype.cpp:
2894         (JSC::IntlCollatorPrototype::finishCreation):
2895         * runtime/IntlDateTimeFormatPrototype.cpp:
2896         (JSC::IntlDateTimeFormatPrototype::finishCreation):
2897         * runtime/IntlNumberFormatPrototype.cpp:
2898         (JSC::IntlNumberFormatPrototype::finishCreation):
2899         * runtime/IntlPluralRulesPrototype.cpp:
2900         (JSC::IntlPluralRulesPrototype::finishCreation):
2901         * runtime/JSArrayBufferPrototype.cpp:
2902         (JSC::JSArrayBufferPrototype::finishCreation):
2903         * runtime/JSDataViewPrototype.cpp:
2904         (JSC::JSDataViewPrototype::finishCreation):
2905         * runtime/JSGenericTypedArrayViewPrototypeInlines.h:
2906         (JSC::JSGenericTypedArrayViewPrototype<ViewClass>::finishCreation):
2907         * runtime/JSGlobalObject.cpp:
2908         (JSC::createConsoleProperty):
2909         * runtime/JSPromisePrototype.cpp:
2910         (JSC::JSPromisePrototype::finishCreation):
2911         * runtime/JSTypedArrayViewConstructor.cpp:
2912         (JSC::JSTypedArrayViewConstructor::finishCreation):
2913         * runtime/JSTypedArrayViewPrototype.cpp:
2914         (JSC::JSTypedArrayViewPrototype::finishCreation):
2915         * runtime/NumberPrototype.cpp:
2916         (JSC::NumberPrototype::finishCreation):
2917         * runtime/RegExpPrototype.cpp:
2918         (JSC::RegExpPrototype::finishCreation):
2919         * runtime/StringPrototype.cpp:
2920         (JSC::StringPrototype::finishCreation):
2921         * runtime/Structure.cpp:
2922         (JSC::Structure::isValidPrototype):
2923         (JSC::Structure::changePrototypeTransition):
2924         * runtime/Structure.h:
2925         * runtime/SymbolPrototype.cpp:
2926         (JSC::SymbolPrototype::finishCreation):
2927         * wasm/js/WebAssemblyCompileErrorPrototype.cpp:
2928         (JSC::WebAssemblyCompileErrorPrototype::finishCreation):
2929         * wasm/js/WebAssemblyInstancePrototype.cpp:
2930         (JSC::WebAssemblyInstancePrototype::finishCreation):
2931         * wasm/js/WebAssemblyLinkErrorPrototype.cpp:
2932         (JSC::WebAssemblyLinkErrorPrototype::finishCreation):
2933         * wasm/js/WebAssemblyMemoryPrototype.cpp:
2934         (JSC::WebAssemblyMemoryPrototype::finishCreation):
2935         * wasm/js/WebAssemblyModulePrototype.cpp:
2936         (JSC::WebAssemblyModulePrototype::finishCreation):
2937         * wasm/js/WebAssemblyPrototype.cpp:
2938         (JSC::WebAssemblyPrototype::finishCreation):
2939         * wasm/js/WebAssemblyRuntimeErrorPrototype.cpp:
2940         (JSC::WebAssemblyRuntimeErrorPrototype::finishCreation):
2941         * wasm/js/WebAssemblyTablePrototype.cpp:
2942         (JSC::WebAssemblyTablePrototype::finishCreation):
2943
2944 2019-05-07  Robin Morisset  <rmorisset@apple.com>
2945
2946         WTF::BitVector should have an isEmpty() method
2947         https://bugs.webkit.org/show_bug.cgi?id=197637
2948
2949         Reviewed by Keith Miller.
2950
2951         Just replaces some comparison of bitCount() to 0 by calls to isEmpty()
2952
2953         * b3/air/AirAllocateRegistersByGraphColoring.cpp:
2954
2955 2019-05-07  Commit Queue  <commit-queue@webkit.org>
2956
2957         Unreviewed, rolling out r244978.
2958         https://bugs.webkit.org/show_bug.cgi?id=197671
2959
2960         TemplateObject map should use start/end offsets (Requested by
2961         yusukesuzuki on #webkit).
2962
2963         Reverted changeset:
2964
2965         "TemplateObject passed to template literal tags are not always
2966         identical for the same source location."
2967         https://bugs.webkit.org/show_bug.cgi?id=190756
2968         https://trac.webkit.org/changeset/244978
2969
2970 2019-05-07  Tadeu Zagallo  <tzagallo@apple.com>
2971
2972         tryCachePutByID should not crash if target offset changes
2973         https://bugs.webkit.org/show_bug.cgi?id=197311
2974         <rdar://problem/48033612>
2975
2976         Reviewed by Filip Pizlo.
2977
2978         When tryCachePutID is called with a cacheable setter, if the target object where the setter was
2979         found is still in the prototype chain and there's no poly protos in the chain, we use
2980         generateConditionsForPrototypePropertyHit to validate that the target object remains the same.
2981         It checks for the absence of the property in every object in the prototype chain from the base
2982         down to the target object and checks that the property is still present in the target object. It
2983         also bails if there are any uncacheable objects, proxies or dictionary objects in the prototype
2984         chain. However, it does not consider two edge cases:
2985         - It asserts that the property should still be at the same offset in the target object, but this
2986         assertion does not hold if the setter deletes properties of the object and causes the structure
2987         to be flattened after the deletion. Instead of asserting, we just use the updated offset.
2988         - It does not check whether the new slot is also a setter, which leads to a crash in case it's not.
2989
2990         * jit/Repatch.cpp:
2991         (JSC::tryCachePutByID):
2992
2993 2019-05-07  Saam Barati  <sbarati@apple.com>
2994
2995         Don't OSR enter into an FTL CodeBlock that has been jettisoned
2996         https://bugs.webkit.org/show_bug.cgi?id=197531
2997         <rdar://problem/50162379>
2998
2999         Reviewed by Yusuke Suzuki.
3000
3001         Sometimes we make silly mistakes. This is one of those times. It's invalid to OSR
3002         enter into an FTL OSR entry code block that has been jettisoned already.
3003
3004         * dfg/DFGJITCode.cpp:
3005         (JSC::DFG::JITCode::clearOSREntryBlockAndResetThresholds):
3006         * dfg/DFGJITCode.h:
3007         (JSC::DFG::JITCode::clearOSREntryBlock): Deleted.
3008         * dfg/DFGOSREntry.cpp:
3009         (JSC::DFG::prepareOSREntry):
3010         (JSC::DFG::prepareCatchOSREntry):
3011         * dfg/DFGOperations.cpp:
3012         * ftl/FTLOSREntry.cpp:
3013         (JSC::FTL::prepareOSREntry):
3014
3015 2019-05-06  Keith Miller  <keith_miller@apple.com>
3016
3017         JSWrapperMap should check if existing prototype properties are wrappers when copying exported methods.
3018         https://bugs.webkit.org/show_bug.cgi?id=197324
3019         <rdar://problem/50253144>
3020
3021         Reviewed by Saam Barati.
3022
3023         The current implementation prevents using JSExport to shadow a
3024         method from a super class. This was because we would only add a
3025         method if the prototype didn't already claim to have the
3026         property. Normally this would only happen if an Objective-C super
3027         class already exported a ObjCCallbackFunction for the method,
3028         however, if the user exports a property that is already on
3029         Object.prototype the overriden method won't be exported.
3030
3031         This patch fixes the object prototype issue by checking if the
3032         property on the prototype chain is an ObjCCallbackFunction, if
3033         it's not then it adds an override.
3034
3035         * API/JSWrapperMap.mm:
3036         (copyMethodsToObject):
3037         * API/tests/testapi.mm:
3038         (-[ToStringClass toString]):
3039         (-[ToStringClass other]):
3040         (-[ToStringSubclass toString]):
3041         (-[ToStringSubclassNoProtocol toString]):
3042         (testToString):
3043         (testObjectiveCAPI):
3044
3045 2019-05-06  Yusuke Suzuki  <ysuzuki@apple.com>
3046
3047         [JSC] We should check OOM for description string of Symbol
3048         https://bugs.webkit.org/show_bug.cgi?id=197634
3049
3050         Reviewed by Keith Miller.
3051
3052         When resoling JSString for description of Symbol, we should check OOM error.
3053         We also change JSValueMakeSymbol(..., nullptr) to returning a symbol value
3054         without description, (1) to simplify the code and (2) give a way for JSC API
3055         to create a symbol value without description.
3056
3057         * API/JSValueRef.cpp:
3058         (JSValueMakeSymbol):
3059         * API/tests/testapi.cpp:
3060         (TestAPI::symbolsTypeof):
3061         (TestAPI::symbolsDescription):
3062         (testCAPIViaCpp):
3063         * dfg/DFGOperations.cpp:
3064         * runtime/Symbol.cpp:
3065         (JSC::Symbol::createWithDescription):
3066         * runtime/Symbol.h:
3067         * runtime/SymbolConstructor.cpp:
3068         (JSC::callSymbol):
3069
3070 2019-05-06  Keith Rollin  <krollin@apple.com>
3071
3072         Temporarily disable generate-xcfilelists
3073         https://bugs.webkit.org/show_bug.cgi?id=197619
3074         <rdar://problem/50507392>
3075
3076         Reviewed by Alex Christensen.
3077
3078         We need to perform a significant update to the generate-xcfilelist
3079         scripts. This work involves coordinated work with another facility. If
3080         the work does not occur in tandem, the build will be broken. To avoid
3081         this, disable the invoking of the scripts during the transition. The
3082         checking will be restored once the new scripts are in place.
3083
3084         * Scripts/check-xcfilelists.sh:
3085
3086 2019-05-06  Basuke Suzuki  <Basuke.Suzuki@sony.com>
3087
3088         [PlayStation] Fix build break since r244919
3089         https://bugs.webkit.org/show_bug.cgi?id=197627
3090
3091         Reviewed by Ross Kirsling.
3092
3093         Bugfix for POSIX socket implementation and suppress warnings.
3094
3095         * inspector/remote/socket/RemoteInspectorConnectionClient.h:
3096         (Inspector::RemoteInspectorConnectionClient::didAccept):
3097         * inspector/remote/socket/posix/RemoteInspectorSocketPOSIX.cpp:
3098         (Inspector::Socket::getPort):
3099
3100 2019-05-06  Yusuke Suzuki  <ysuzuki@apple.com>
3101
3102         TemplateObject passed to template literal tags are not always identical for the same source location.
3103         https://bugs.webkit.org/show_bug.cgi?id=190756
3104
3105         Reviewed by Saam Barati.
3106
3107         Tagged template literal requires that the site object is allocated per source location. Previously, we create the site object
3108         when linking CodeBlock and cache it in CodeBlock. But this is wrong because,
3109
3110         1. CodeBlock can be jettisoned and regenerated. So every time CodeBlock is regenerated, we get the different site object.
3111         2. Call and Construct can have different CodeBlock. Even if the function is called in call-form or construct-form, we should return the same site object.
3112
3113         In this patch, we start caching these site objects in the top-level ScriptExecutable, this matches the spec's per source location since the only one top-level
3114         ScriptExecutable is created for the given script code. Each ScriptExecutable of JSFunction can be created multiple times because CodeBlock creates it.
3115         But the top-level one is not created by CodeBlock. This top-level ScriptExecutable is well-aligned to the Script itself. The top-level ScriptExecutable now has HashMap,
3116         which maps source locations to cached site objects.
3117
3118         1. This patch threads the top-level ScriptExecutable to each FunctionExecutable creation. Each FunctionExecutable has a reference to the top-level ScriptExecutable.
3119         2. We put TemplateObjectMap in ScriptExecutable, which manages cached template objects.
3120         3. We move FunctionExecutable::m_cachedPolyProtoStructure to the FunctionExecutable::RareDate to keep FunctionExecutable 128 bytes.
3121
3122         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
3123         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
3124         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
3125         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result:
3126         * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
3127         * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result:
3128         * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result:
3129         * Scripts/tests/builtins/expected/WebCore-AnotherGuardedInternalBuiltin-Separate.js-result:
3130         * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
3131         * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
3132         * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
3133         * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
3134         * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
3135         * Scripts/wkbuiltins/builtins_templates.py:
3136         * bytecode/CodeBlock.cpp:
3137         (JSC::CodeBlock::finishCreation):
3138         (JSC::CodeBlock::setConstantRegisters):
3139         * bytecode/CodeBlock.h:
3140         * bytecode/UnlinkedFunctionExecutable.cpp:
3141         (JSC::UnlinkedFunctionExecutable::link):
3142         * bytecode/UnlinkedFunctionExecutable.h:
3143         * bytecompiler/BytecodeGenerator.cpp:
3144         (JSC::BytecodeGenerator::addTemplateObjectConstant):
3145         (JSC::BytecodeGenerator::emitGetTemplateObject):
3146         * bytecompiler/BytecodeGenerator.h:
3147         * runtime/CachedTypes.cpp:
3148         (JSC::CachedTemplateObjectDescriptor::encode):
3149         (JSC::CachedTemplateObjectDescriptor::decode const):
3150         (JSC::CachedJSValue::encode):
3151         (JSC::CachedJSValue::decode const):
3152         * runtime/EvalExecutable.cpp:
3153         (JSC::EvalExecutable::ensureTemplateObjectMap):
3154         (JSC::EvalExecutable::visitChildren):
3155         * runtime/EvalExecutable.h:
3156         * runtime/FunctionExecutable.cpp:
3157         (JSC::FunctionExecutable::finishCreation):
3158         (JSC::FunctionExecutable::visitChildren):
3159         (JSC::FunctionExecutable::fromGlobalCode):
3160         (JSC::FunctionExecutable::ensureRareDataSlow):
3161         (JSC::FunctionExecutable::ensureTemplateObjectMap):
3162         * runtime/FunctionExecutable.h:
3163         * runtime/JSModuleRecord.cpp:
3164         (JSC::JSModuleRecord::instantiateDeclarations):
3165         * runtime/JSTemplateObjectDescriptor.cpp:
3166         (JSC::JSTemplateObjectDescriptor::JSTemplateObjectDescriptor):
3167         (JSC::JSTemplateObjectDescriptor::create):
3168         * runtime/JSTemplateObjectDescriptor.h:
3169         * runtime/ModuleProgramExecutable.cpp:
3170         (JSC::ModuleProgramExecutable::ensureTemplateObjectMap):
3171         (JSC::ModuleProgramExecutable::visitChildren):
3172         * runtime/ModuleProgramExecutable.h:
3173         * runtime/ProgramExecutable.cpp:
3174         (JSC::ProgramExecutable::ensureTemplateObjectMap):
3175         (JSC::ProgramExecutable::visitChildren):
3176         * runtime/ProgramExecutable.h:
3177         * runtime/ScriptExecutable.cpp:
3178         (JSC::ScriptExecutable::topLevelExecutable):
3179         (JSC::ScriptExecutable::createTemplateObject):
3180         (JSC::ScriptExecutable::ensureTemplateObjectMap):
3181         * runtime/ScriptExecutable.h:
3182         * tools/JSDollarVM.cpp:
3183         (JSC::functionCreateBuiltin):
3184         (JSC::functionDeleteAllCodeWhenIdle):
3185         (JSC::JSDollarVM::finishCreation):
3186
3187 2019-05-04  Tadeu Zagallo  <tzagallo@apple.com>
3188
3189         TypedArrays should not store properties that are canonical numeric indices
3190         https://bugs.webkit.org/show_bug.cgi?id=197228
3191         <rdar://problem/49557381>
3192
3193         Reviewed by Saam Barati.
3194
3195         According to the spec[1]:
3196         - TypedArrays should not perform an ordinary GetOwnProperty/SetOwnProperty if the index is a
3197         CanonicalNumericIndexString, but invalid according to IntegerIndexedElementGet and similar
3198         functions. I.e., there are a few properties that should not be set in a TypedArray, like NaN,
3199         Infinity and -0.
3200         - On DefineOwnProperty, the out-of-bounds check should be performed before validating the property
3201         descriptor.
3202         - On GetOwnProperty, the returned descriptor for numeric properties should have writable set to true.
3203
3204         [1]: https://www.ecma-international.org/ecma-262/9.0/index.html#sec-integer-indexed-exotic-objects-defineownproperty-p-desc
3205
3206         * CMakeLists.txt:
3207         * JavaScriptCore.xcodeproj/project.pbxproj:
3208         * runtime/JSGenericTypedArrayViewInlines.h:
3209         (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlot):
3210         (JSC::JSGenericTypedArrayView<Adaptor>::put):
3211         (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
3212         (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlotByIndex):
3213         (JSC::JSGenericTypedArrayView<Adaptor>::putByIndex):
3214         * runtime/PropertyName.h:
3215         (JSC::isCanonicalNumericIndexString):
3216
3217 2019-05-03  Yusuke Suzuki  <ysuzuki@apple.com>
3218
3219         [JSC] Need to emit SetLocal if we emit MovHint in DFGByteCodeParser
3220         https://bugs.webkit.org/show_bug.cgi?id=197584
3221
3222         Reviewed by Saam Barati.
3223
3224         In r244864, we emit MovHint for adhocly created GetterCall/SetterCall frame locals in the callee side to make OSR availability analysis's pruning correct.
3225         However, we just emit MovHint, and we do not emit SetLocal since we ensured that these locals are already flushed in the same place before. However, MovHint
3226         and SetLocal are needed to be a pair in DFGByteCodeParser because we rely on this assumption in SSA conversion phase. SSA conversion phase always emit KillStack
3227         just before MovHint's target location even if the MovHint's target is the same to the previously emitted MovHint and SetLocal.
3228         This patch emits SetLocal too when emitting MovHint for GetterCall/SetterCall frame locals.
3229
3230         The example is like this.
3231
3232             a:  SomeValueNode
3233              :  MovHint(@a, loc10)
3234             b:  SetLocal(@a, loc10)
3235                 ...
3236             c:  MovHint(@a, loc10)
3237
3238         Then, this will be converted to the style in SSA conversion.
3239
3240             a:  SomeValueNode
3241              :  KillStack(loc10)
3242             b:  PutStack(@a, loc10)
3243                 ...
3244             c:  KillStack(loc10)
3245
3246         Then, @b will be removed later since @c kills it.
3247
3248         * dfg/DFGByteCodeParser.cpp:
3249         (JSC::DFG::ByteCodeParser::inlineCall):
3250         * heap/MarkedBlock.cpp:
3251         (JSC::MarkedBlock::MarkedBlock):
3252         (JSC::MarkedBlock::Handle::stopAllocating):
3253         (JSC::MarkedBlock::Handle::resumeAllocating):
3254         (JSC::MarkedBlock::aboutToMarkSlow):
3255         (JSC::MarkedBlock::Handle::didConsumeFreeList):
3256
3257 2019-05-03  Devin Rousso  <drousso@apple.com>
3258
3259         Web Inspector: DOM: rename "low power" to "display composited"
3260         https://bugs.webkit.org/show_bug.cgi?id=197296
3261
3262         Reviewed by Joseph Pecoraro.
3263
3264         Removed specific ChangeLog entries since it is almost entirely mechanical changes.
3265
3266         * inspector/protocol/DOM.json:
3267
3268 2019-05-03  Basuke Suzuki  <Basuke.Suzuki@sony.com>
3269
3270         [WinCairo] Implement and enable RemoteInspector Server.
3271         https://bugs.webkit.org/show_bug.cgi?id=197432
3272
3273         Reviewed by Ross Kirsling.
3274
3275         Implement Windows implementation for Socket Backend of RemoteInspector and enable it on WinCairo
3276         for experimental feature.
3277
3278         Also add listener interface for connection between RemoteInspector and RemoteInspectorServer
3279         for flexible configuration.
3280
3281         * PlatformWin.cmake:
3282         * inspector/remote/RemoteInspector.h:
3283         * inspector/remote/socket/RemoteInspectorConnectionClient.h:
3284         (Inspector::RemoteInspectorConnectionClient::didAccept):
3285         * inspector/remote/socket/RemoteInspectorServer.cpp:
3286         (Inspector::RemoteInspectorServer::connect):
3287         (Inspector::RemoteInspectorServer::listenForTargets):
3288         (Inspector::RemoteInspectorServer::didAccept):
3289         (Inspector::RemoteInspectorServer::dispatchMap):
3290         (Inspector::RemoteInspectorServer::start):
3291         (Inspector::RemoteInspectorServer::addServerConnection): Deleted.
3292         * inspector/remote/socket/RemoteInspectorServer.h:
3293         (Inspector::RemoteInspectorServer::RemoteInspectorServer):
3294         * inspector/remote/socket/RemoteInspectorSocket.cpp:
3295         (Inspector::RemoteInspector::RemoteInspector):
3296         (Inspector::RemoteInspector::dispatchMap):
3297         (Inspector::RemoteInspector::start):
3298         (Inspector::RemoteInspector::stopInternal):
3299         (Inspector::RemoteInspector::setServerPort):
3300         * inspector/remote/socket/RemoteInspectorSocket.h:
3301         * inspector/remote/socket/RemoteInspectorSocketEndpoint.cpp:
3302         (Inspector::RemoteInspectorSocketEndpoint::listenInet):
3303         (Inspector::RemoteInspectorSocketEndpoint::getPort const):
3304         (Inspector::RemoteInspectorSocketEndpoint::acceptInetSocketIfEnabled):
3305         * inspector/remote/socket/RemoteInspectorSocketEndpoint.h:
3306         * inspector/remote/socket/posix/RemoteInspectorSocketPOSIX.cpp:
3307         (Inspector::Socket::init): Added.
3308         (Inspector::Socket::listen): Signature changed.
3309         (Inspector::Socket::getPort): Added.
3310         * inspector/remote/socket/win/RemoteInspectorSocketWin.cpp: Added.
3311         (Inspector::Socket::init):
3312         (Inspector::Socket::Socket::Socket):
3313         (Inspector::Socket::Socket::~Socket):
3314         (Inspector::Socket::Socket::close):
3315         (Inspector::Socket::Socket::operator PlatformSocketType const):
3316         (Inspector::Socket::Socket::operator bool const):
3317         (Inspector::Socket::Socket::leak):
3318         (Inspector::Socket::Socket::create):
3319         (Inspector::Socket::setOpt):
3320         (Inspector::Socket::setOptEnabled):
3321         (Inspector::Socket::enableOpt):
3322         (Inspector::Socket::connectTo):
3323         (Inspector::Socket::bindAndListen):
3324         (Inspector::Socket::connect):
3325         (Inspector::Socket::listen):
3326         (Inspector::Socket::accept):
3327         (Inspector::Socket::createPair):
3328         (Inspector::Socket::setup):
3329         (Inspector::Socket::isValid):
3330         (Inspector::Socket::isListening):
3331         (Inspector::Socket::getPort):
3332         (Inspector::Socket::read):
3333         (Inspector::Socket::write):
3334         (Inspector::Socket::close):
3335         (Inspector::Socket::preparePolling):
3336         (Inspector::Socket::poll):
3337         (Inspector::Socket::isReadable):
3338         (Inspector::Socket::isWritable):
3339         (Inspector::Socket::markWaitingWritable):
3340         (Inspector::Socket::clearWaitingWritable):
3341
3342 2019-05-03  Yusuke Suzuki  <ysuzuki@apple.com>
3343
3344         [JSC] Generator CodeBlock generation should be idempotent
3345         https://bugs.webkit.org/show_bug.cgi?id=197552
3346
3347         Reviewed by Keith Miller.
3348
3349         ES6 Generator saves and resumes the current execution state. Since ES6 generator can save the execution state at expression
3350         granularity (not statement granularity), the saved state involves locals. But if the underlying CodeBlock is jettisoned and
3351         recompiled with different code generation option (like, debugger, type profiler etc.), the generated instructions can be largely
3352         different and it does not have the same state previously used. If we resume the previously created generator with the newly
3353         generator function, resuming is messed up.
3354
3355             function* gen () { ... }
3356             var g = gen();
3357             g.next();
3358
3359             // CodeBlock is destroyed & Debugger is enabled.
3360
3361             g.next();
3362
3363         In this patch,
3364
3365         1. In generatorification, we use index Identifier (localN => Identifier("N")) instead of private symbols to generate the same
3366            instructions every time we regenerate the CodeBlock.
3367
3368         2. We decouple the options which can affect on the generated code (Debugger, TypeProfiler, ControlFlowProfiler) from the BytecodeGenerator,
3369            and pass them as a parameter, OptionSet<CodeGeneratorMode>.
3370
3371         3. Generator ScriptExecutable remembers the previous CodeGeneratorMode and reuses this parameter to regenerate CodeBlock. It means that,
3372            even if the debugger is enabled, previously created generators are not debuggable. But newly created generators are debuggable.
3373
3374         * bytecode/BytecodeGeneratorification.cpp:
3375         (JSC::BytecodeGeneratorification::storageForGeneratorLocal):
3376         (JSC::BytecodeGeneratorification::run):
3377         * bytecode/CodeBlock.cpp:
3378         (JSC::CodeBlock::finishCreation):
3379         (JSC::CodeBlock::setConstantRegisters):
3380         * bytecode/UnlinkedCodeBlock.cpp:
3381         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
3382         * bytecode/UnlinkedCodeBlock.h:
3383         (JSC::UnlinkedCodeBlock::wasCompiledWithDebuggingOpcodes const):
3384         (JSC::UnlinkedCodeBlock::wasCompiledWithTypeProfilerOpcodes const):
3385         (JSC::UnlinkedCodeBlock::wasCompiledWithControlFlowProfilerOpcodes const):
3386         (JSC::UnlinkedCodeBlock::codeGenerationMode const):
3387         * bytecode/UnlinkedEvalCodeBlock.h:
3388         * bytecode/UnlinkedFunctionCodeBlock.h:
3389         * bytecode/UnlinkedFunctionExecutable.cpp:
3390         (JSC::generateUnlinkedFunctionCodeBlock):
3391         (JSC::UnlinkedFunctionExecutable::fromGlobalCode):
3392         (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
3393         * bytecode/UnlinkedFunctionExecutable.h:
3394         * bytecode/UnlinkedGlobalCodeBlock.h:
3395         (JSC::UnlinkedGlobalCodeBlock::UnlinkedGlobalCodeBlock):
3396         * bytecode/UnlinkedModuleProgramCodeBlock.h:
3397         * bytecode/UnlinkedProgramCodeBlock.h:
3398         * bytecompiler/BytecodeGenerator.cpp:
3399         (JSC::BytecodeGenerator::BytecodeGenerator):
3400         (JSC::BytecodeGenerator::emitTypeProfilerExpressionInfo):
3401         (JSC::BytecodeGenerator::emitProfileType):
3402         (JSC::BytecodeGenerator::emitProfileControlFlow):
3403         (JSC::BytecodeGenerator::pushLexicalScopeInternal):
3404         (JSC::BytecodeGenerator::popLexicalScopeInternal):
3405         (JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
3406         (JSC::BytecodeGenerator::emitCall):
3407         (JSC::BytecodeGenerator::emitCallVarargs):
3408         (JSC::BytecodeGenerator::emitLogShadowChickenPrologueIfNecessary):
3409         (JSC::BytecodeGenerator::emitLogShadowChickenTailIfNecessary):
3410         (JSC::BytecodeGenerator::emitDebugHook):
3411         * bytecompiler/BytecodeGenerator.h:
3412         (JSC::BytecodeGenerator::generate):
3413         (JSC::BytecodeGenerator::shouldEmitDebugHooks const):
3414         (JSC::BytecodeGenerator::shouldEmitTypeProfilerHooks const):
3415         (JSC::BytecodeGenerator::shouldEmitControlFlowProfilerHooks const):
3416         * bytecompiler/NodesCodegen.cpp:
3417         (JSC::PrefixNode::emitResolve):
3418         (JSC::EmptyVarExpression::emitBytecode):
3419         (JSC::ReturnNode::emitBytecode):
3420         (JSC::FunctionNode::emitBytecode):
3421         * parser/ParserModes.h:
3422         (): Deleted.
3423         * parser/SourceCodeKey.h:
3424         (JSC::SourceCodeFlags::SourceCodeFlags):
3425         (JSC::SourceCodeKey::SourceCodeKey):
3426         * runtime/CachedTypes.cpp:
3427         (JSC::CachedCodeBlock::isClassContext const):
3428         (JSC::CachedCodeBlock::codeGenerationMode const):
3429         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
3430         (JSC::CachedCodeBlock<CodeBlockType>::encode):
3431         (JSC::CachedCodeBlock::wasCompiledWithDebuggingOpcodes const): Deleted.
3432         * runtime/CodeCache.cpp:
3433         (JSC::CodeCache::getUnlinkedGlobalCodeBlock):
3434         (JSC::CodeCache::getUnlinkedProgramCodeBlock):
3435         (JSC::CodeCache::getUnlinkedEvalCodeBlock):
3436         (JSC::CodeCache::getUnlinkedModuleProgramCodeBlock):
3437         (JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
3438         (JSC::generateUnlinkedCodeBlockForFunctions):
3439         (JSC::sourceCodeKeyForSerializedBytecode):
3440         (JSC::sourceCodeKeyForSerializedProgram):
3441         (JSC::sourceCodeKeyForSerializedModule):
3442         (JSC::serializeBytecode):
3443         * runtime/CodeCache.h:
3444         (JSC::generateUnlinkedCodeBlockImpl):
3445         (JSC::generateUnlinkedCodeBlock):
3446         * runtime/Completion.cpp:
3447         (JSC::generateProgramBytecode):
3448         (JSC::generateModuleBytecode):
3449         * runtime/DirectEvalExecutable.cpp:
3450         (JSC::DirectEvalExecutable::create):
3451         * runtime/IndirectEvalExecutable.cpp:
3452         (JSC::IndirectEvalExecutable::create):
3453         * runtime/JSGlobalObject.h:
3454         (JSC::JSGlobalObject::defaultCodeGenerationMode const):
3455         * runtime/ModuleProgramExecutable.cpp:
3456         (JSC::ModuleProgramExecutable::create):
3457         * runtime/ProgramExecutable.cpp:
3458         (JSC::ProgramExecutable::initializeGlobalProperties):
3459         * runtime/ScriptExecutable.cpp:
3460         (JSC::ScriptExecutable::ScriptExecutable):
3461         (JSC::ScriptExecutable::newCodeBlockFor):
3462         * runtime/ScriptExecutable.h:
3463         * tools/JSDollarVM.cpp:
3464         (JSC::changeDebuggerModeWhenIdle):
3465         (JSC::functionEnableDebuggerModeWhenIdle):
3466         (JSC::functionDisableDebuggerModeWhenIdle):
3467
3468 2019-05-03  Devin Rousso  <drousso@apple.com>
3469
3470         Web Inspector: Record actions performed on WebGL2RenderingContext
3471         https://bugs.webkit.org/show_bug.cgi?id=176008
3472         <rdar://problem/34213884>
3473
3474         Reviewed by Joseph Pecoraro.
3475
3476         * inspector/protocol/Recording.json:
3477         * inspector/scripts/codegen/generator.py:
3478         Add `canvas-webgl2` as a `Type`.
3479
3480 2019-05-03  Commit Queue  <commit-queue@webkit.org>
3481
3482         Unreviewed, rolling out r244881.
3483         https://bugs.webkit.org/show_bug.cgi?id=197559
3484
3485         Breaks compilation of jsconly on linux, breaking compilation
3486         for jsc-i386-ews, jsc-mips-ews and jsc-armv7-ews (Requested by
3487         guijemont on #webkit).
3488
3489         Reverted changeset:
3490
3491         "[CMake] Refactor WEBKIT_MAKE_FORWARDING_HEADERS into
3492         WEBKIT_COPY_FILES"
3493         https://bugs.webkit.org/show_bug.cgi?id=197174
3494         https://trac.webkit.org/changeset/244881
3495
3496 2019-05-02  Don Olmstead  <don.olmstead@sony.com>
3497
3498         [CMake] Refactor WEBKIT_MAKE_FORWARDING_HEADERS into WEBKIT_COPY_FILES
3499         https://bugs.webkit.org/show_bug.cgi?id=197174
3500
3501         Reviewed by Alex Christensen.
3502
3503         Replace WEBKIT_MAKE_FORWARDING_HEADERS with WEBKIT_COPY_FILES and make dependencies
3504         for framework headers explicit.
3505
3506         * CMakeLists.txt:
3507
3508 2019-05-02  Michael Saboff  <msaboff@apple.com>
3509
3510         Unreviewed rollout of r244862.
3511
3512         * runtime/JSObject.cpp:
3513         (JSC::JSObject::getOwnPropertyDescriptor):
3514
3515 2019-05-01  Saam barati  <sbarati@apple.com>
3516
3517         Baseline JIT should do argument value profiling after checking for stack overflow
3518         https://bugs.webkit.org/show_bug.cgi?id=197052
3519         <rdar://problem/50009602>
3520
3521         Reviewed by Yusuke Suzuki.
3522
3523         Otherwise, we may do value profiling without running a write barrier, which
3524         is against the rules of how we do value profiling.
3525
3526         * jit/JIT.cpp:
3527         (JSC::JIT::compileWithoutLinking):
3528
3529 2019-05-01  Yusuke Suzuki  <ysuzuki@apple.com>
3530
3531         [JSC] Inlining Getter/Setter should care availability of ad-hocly constructed frame
3532         https://bugs.webkit.org/show_bug.cgi?id=197405
3533
3534         Reviewed by Saam Barati.
3535
3536         When inlining getter and setter calls, we setup a stack frame which does not appear in the bytecode.
3537         Because Inlining can switch on executable, we could have a graph like this.
3538
3539         BB#0
3540             ...
3541             30: GetSetter
3542             31: MovHint(loc10)
3543             32: SetLocal(loc10)
3544             33: MovHint(loc9)
3545             34: SetLocal(loc9)
3546             ...
3547             37: GetExecutable(@30)
3548             ...
3549             41: Switch(@37)
3550
3551         BB#2
3552             42: GetLocal(loc12, bc#7 of caller)
3553             ...
3554             --> callee: loc9 and loc10 are arguments of callee.
3555               ...
3556               <HERE, exit to callee, loc9 and loc10 are required in the bytecode>
3557
3558         When we prune OSR availability at the beginning of BB#2 (bc#7 in the caller), we prune loc9 and loc10's liveness because the caller does not actually have loc9 and loc10.
3559         However, when we begin executing the callee, we need OSR exit to be aware of where it can recover the arguments to the setter, loc9 and loc10.
3560
3561         This patch inserts MovHint at the beginning of callee for a getter / setter stack frame to make arguments (loc9 and loc10 in the above example) recoverable from OSR exit.
3562         We also move arity fixup DFG nodes from the caller to the callee, since moved arguments are not live in the caller too.
3563
3564         Interestingly, this fix also reveals the existing issue in LiveCatchVariablePreservationPhase. We emitted Flush for |this| of InlineCallFrame blindly if we saw InlineCallFrame
3565         inside a block which is covered by catch handler. But this is wrong because inlined function can finish its execution within the block, and |this| is completely unrelated to
3566         the catch handler if the catch handler is in the outer callee. We already collect all the live locals at the catch handler. And this locals must include arguments too if the
3567         catch handler is in inlined function. So, we should not emit Flush for each |this| of seen InlineCallFrame. This emitted Flush may connect unrelated locals in the catch handler
3568         to the locals that is only defined and used in the inlined function, and it leads to the results like DFG says the local is live while the bytecode says the local is dead.
3569         This results in reading and using garbage in OSR entry because DFG OSR entry needs to fill live DFG values from the stack.
3570
3571         * dfg/DFGByteCodeParser.cpp:
3572         (JSC::DFG::ByteCodeParser::inlineCall):
3573         (JSC::DFG::ByteCodeParser::handleGetById):
3574         (JSC::DFG::ByteCodeParser::handlePutById):
3575         * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
3576         (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlockForTryCatch):
3577
3578 2019-05-01  Michael Saboff  <msaboff@apple.com>
3579
3580         ASSERTION FAILED: !m_needExceptionCheck with --validateExceptionChecks=1; ProxyObject.getOwnPropertySlotCommon/JSFunction.callerGetter
3581         https://bugs.webkit.org/show_bug.cgi?id=197485
3582
3583         Reviewed by Saam Barati.
3584
3585         Added an EXCEPTION_ASSERT after call to getOwnPropertySlot().
3586
3587         * runtime/JSObject.cpp:
3588         (JSC::JSObject::getOwnPropertyDescriptor):
3589
3590 2019-05-01  Ross Kirsling  <ross.kirsling@sony.com>
3591
3592         RemoteInspector::updateAutomaticInspectionCandidate should have a default implementation.
3593         https://bugs.webkit.org/show_bug.cgi?id=197439
3594
3595         Reviewed by Devin Rousso.
3596
3597         On non-Cocoa platforms, automatic inspection is not currently implemented,
3598         so updateAutomaticInspectionCandidate falls back to the logic of updateTarget.
3599         This logic already existed in three places, so refactor it into a common private method
3600         and allow our websocket-based RWI implementation to make use of it too.
3601
3602         * inspector/remote/RemoteInspector.cpp:
3603         (Inspector::RemoteInspector::updateTarget):
3604         (Inspector::RemoteInspector::updateTargetMap):
3605         (Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
3606         * inspector/remote/RemoteInspector.h:
3607         * inspector/remote/cocoa/RemoteInspectorCocoa.mm:
3608         (Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
3609         * inspector/remote/glib/RemoteInspectorGlib.cpp:
3610         (Inspector::RemoteInspector::updateAutomaticInspectionCandidate): Deleted.
3611         * inspector/remote/socket/RemoteInspectorSocket.cpp:
3612         (Inspector::RemoteInspector::updateAutomaticInspectionCandidate): Deleted.
3613
3614 2019-05-01  Darin Adler  <darin@apple.com>
3615
3616         WebKit has too much of its own UTF-8 code and should rely more on ICU's UTF-8 support
3617         https://bugs.webkit.org/show_bug.cgi?id=195535
3618
3619         Reviewed by Alexey Proskuryakov.
3620
3621         * API/JSClassRef.cpp: Removed uneeded include of UTF8Conversion.h.
3622
3623         * API/JSStringRef.cpp:
3624         (JSStringCreateWithUTF8CString): Updated for changes to convertUTF8ToUTF16.
3625         (JSStringGetUTF8CString): Updated for changes to convertLatin1ToUTF8.
3626         Removed unneeded "true" to get the strict version of convertUTF16ToUTF8,
3627         since that is the default. Also updated for changes to CompletionResult.
3628
3629         * runtime/JSGlobalObjectFunctions.cpp:
3630         (JSC::decode): Stop using UTF8SequenceLength, and instead use U8_COUNT_TRAIL_BYTES
3631         and U8_MAX_LENGTH. Instead of decodeUTF8Sequence, use U8_NEXT. Also use U_IS_BMP,
3632         U_IS_SUPPLEMENTARY, U16_LEAD, U16_TRAIL, and U_IS_SURROGATE instead of our own
3633         equivalents, since these macros from ICU are correct and efficient.
3634
3635         * wasm/WasmParser.h:
3636         (JSC::Wasm::Parser<SuccessType>::consumeUTF8String): Updated for changes to
3637         convertUTF8ToUTF16.
3638
3639 2019-05-01  Shawn Roberts  <sroberts@apple.com>
3640
3641         Unreviewed, rolling out r244821.
3642
3643         Causing
3644
3645         Reverted changeset:
3646
3647         "WebKit has too much of its own UTF-8 code and should rely
3648         more on ICU's UTF-8 support"
3649         https://bugs.webkit.org/show_bug.cgi?id=195535
3650         https://trac.webkit.org/changeset/244821
3651
3652 2019-04-29  Darin Adler  <darin@apple.com>
3653
3654         WebKit has too much of its own UTF-8 code and should rely more on ICU's UTF-8 support
3655         https://bugs.webkit.org/show_bug.cgi?id=195535
3656
3657         Reviewed by Alexey Proskuryakov.
3658
3659         * API/JSClassRef.cpp: Removed uneeded include of UTF8Conversion.h.
3660
3661         * API/JSStringRef.cpp:
3662         (JSStringCreateWithUTF8CString): Updated for changes to convertUTF8ToUTF16.
3663         (JSStringGetUTF8CString): Updated for changes to convertLatin1ToUTF8.
3664         Removed unneeded "true" to get the strict version of convertUTF16ToUTF8,
3665         since that is the default. Also updated for changes to CompletionResult.
3666
3667         * runtime/JSGlobalObjectFunctions.cpp:
3668         (JSC::decode): Stop using UTF8SequenceLength, and instead use U8_COUNT_TRAIL_BYTES
3669         and U8_MAX_LENGTH. Instead of decodeUTF8Sequence, use U8_NEXT. Also use U_IS_BMP,
3670         U_IS_SUPPLEMENTARY, U16_LEAD, U16_TRAIL, and U_IS_SURROGATE instead of our own
3671         equivalents, since these macros from ICU are correct and efficient.
3672
3673         * wasm/WasmParser.h:
3674         (JSC::Wasm::Parser<SuccessType>::consumeUTF8String): Updated for changes to
3675         convertUTF8ToUTF16.
3676
3677 2019-04-30  Commit Queue  <commit-queue@webkit.org>
3678
3679         Unreviewed, rolling out r244806.
3680         https://bugs.webkit.org/show_bug.cgi?id=197446
3681
3682         Causing Test262 and JSC test failures on multiple builds
3683         (Requested by ShawnRoberts on #webkit).
3684
3685         Reverted changeset:
3686
3687         "TypeArrays should not store properties that are canonical
3688         numeric indices"
3689         https://bugs.webkit.org/show_bug.cgi?id=197228
3690         https://trac.webkit.org/changeset/244806
3691
3692 2019-04-30  Saam barati  <sbarati@apple.com>
3693
3694         CodeBlock::m_instructionCount is wrong
3695         https://bugs.webkit.org/show_bug.cgi?id=197304
3696
3697         Reviewed by Yusuke Suzuki.
3698
3699         What we were calling instructionCount() was wrong, as evidenced by
3700         us using it incorrectly both in the sampling profiler and when we
3701         dumped bytecode for a given CodeBlock. Prior to the bytecode rewrite,
3702         instructionCount() was probably valid to do bounds checks against.
3703         However, this is no longer the case. This patch renames what we called
3704         instructionCount() to bytecodeCost(). It is now only used to make decisions
3705         about inlining and tier up heuristics. I've also named options related to
3706         this appropriately.
3707         
3708         This patch also introduces instructionsSize(). The result of this method
3709         is valid to do bounds checks against.
3710
3711         * bytecode/CodeBlock.cpp:
3712         (JSC::CodeBlock::dumpAssumingJITType const):
3713         (JSC::CodeBlock::CodeBlock):
3714         (JSC::CodeBlock::finishCreation):
3715         (JSC::CodeBlock::optimizationThresholdScalingFactor):
3716         (JSC::CodeBlock::predictedMachineCodeSize):
3717         * bytecode/CodeBlock.h:
3718         (JSC::CodeBlock::instructionsSize const):
3719         (JSC::CodeBlock::bytecodeCost const):
3720         (JSC::CodeBlock::instructionCount const): Deleted.
3721         * dfg/DFGByteCodeParser.cpp:
3722         (JSC::DFG::ByteCodeParser::inliningCost):
3723         (JSC::DFG::ByteCodeParser::getInliningBalance):
3724         * dfg/DFGCapabilities.cpp:
3725         (JSC::DFG::mightCompileEval):
3726         (JSC::DFG::mightCompileProgram):
3727         (JSC::DFG::mightCompileFunctionForCall):
3728         (JSC::DFG::mightCompileFunctionForConstruct):
3729         (JSC::DFG::mightInlineFunctionForCall):
3730         (JSC::DFG::mightInlineFunctionForClosureCall):
3731         (JSC::DFG::mightInlineFunctionForConstruct):
3732         * dfg/DFGCapabilities.h:
3733         (JSC::DFG::isSmallEnoughToInlineCodeInto):
3734         * dfg/DFGDisassembler.cpp:
3735         (JSC::DFG::Disassembler::dumpHeader):
3736         * dfg/DFGDriver.cpp:
3737         (JSC::DFG::compileImpl):
3738         * dfg/DFGPlan.cpp:
3739         (JSC::DFG::Plan::compileInThread):
3740         * dfg/DFGTierUpCheckInjectionPhase.cpp:
3741         (JSC::DFG::TierUpCheckInjectionPhase::run):
3742         * ftl/FTLCapabilities.cpp:
3743         (JSC::FTL::canCompile):
3744         * ftl/FTLCompile.cpp:
3745         (JSC::FTL::compile):
3746         * ftl/FTLLink.cpp:
3747         (JSC::FTL::link):
3748         * jit/JIT.cpp:
3749         (JSC::JIT::link):
3750         * jit/JITDisassembler.cpp:
3751         (JSC::JITDisassembler::dumpHeader):
3752         * llint/LLIntSlowPaths.cpp:
3753         (JSC::LLInt::shouldJIT):
3754         * profiler/ProfilerBytecodes.cpp:
3755         (JSC::Profiler::Bytecodes::Bytecodes):
3756         * runtime/Options.h:
3757         * runtime/SamplingProfiler.cpp:
3758         (JSC::tryGetBytecodeIndex):
3759         (JSC::SamplingProfiler::processUnverifiedStackTraces):
3760
3761 2019-04-30  Tadeu Zagallo  <tzagallo@apple.com>
3762
3763         TypeArrays should not store properties that are canonical numeric indices
3764         https://bugs.webkit.org/show_bug.cgi?id=197228
3765         <rdar://problem/49557381>
3766
3767         Reviewed by Darin Adler.
3768
3769         According to the spec[1], TypedArrays should not perform an ordinary GetOwnProperty/SetOwnProperty
3770         if the index is a CanonicalNumericIndexString, but invalid according toIntegerIndexedElementGet
3771         and similar functions. I.e., there are a few properties that should not be set in a TypedArray,
3772         like NaN, Infinity and -0.
3773
3774         [1]: https://www.ecma-international.org/ecma-262/9.0/index.html#sec-integer-indexed-exotic-objects-defineownproperty-p-desc
3775
3776         * CMakeLists.txt:
3777         * JavaScriptCore.xcodeproj/project.pbxproj:
3778         * runtime/JSGenericTypedArrayViewInlines.h:
3779         (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlot):
3780         (JSC::JSGenericTypedArrayView<Adaptor>::put):
3781         (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
3782         (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlotByIndex):
3783         (JSC::JSGenericTypedArrayView<Adaptor>::putByIndex):
3784         * runtime/JSTypedArrays.cpp:
3785         * runtime/PropertyName.h:
3786         (JSC::canonicalNumericIndexString):
3787
3788 2019-04-30  Brian Burg  <bburg@apple.com>
3789
3790         Web Automation: use a more informative key to indicate automation availability
3791         https://bugs.webkit.org/show_bug.cgi?id=197377
3792         <rdar://problem/50258069>
3793
3794         Reviewed by Devin Rousso.
3795
3796         The existing WIRAutomationEnabledKey does not encode uncertainty.
3797         Add a new key that provides an 'Unknown' state, and prefer to use it.
3798
3799         Since an application's initial listing is sent from a background dispatch queue
3800         on Cocoa platforms, this can race with main thread initialization that sets up
3801         RemoteInspector::Client. Therefore, the initial listing may not properly represent
3802         the client's capabilites because the client is not yet available. Allowing for
3803         an "Unknown" state that is later upgraded to Available or Not Available makes it
3804         possible to work around this potential race.
3805
3806         * inspector/remote/RemoteInspectorConstants.h:
3807         * inspector/remote/cocoa/RemoteInspectorCocoa.mm:
3808         (Inspector::RemoteInspector::pushListingsNow):
3809
3810 2019-04-30  Keith Miller  <keith_miller@apple.com>
3811
3812         Fix failing ARM64E wasm tests
3813         https://bugs.webkit.org/show_bug.cgi?id=197420
3814
3815         Reviewed by Saam Barati.
3816
3817         This patch fixes a bug in the slow path of our JS->Wasm IC bridge
3818         where we wouldn't untag the link register before tail calling.
3819
3820         Additionally, this patch fixes a broken assert when using setting
3821         Options::useTailCalls=false.
3822
3823         * bytecompiler/BytecodeGenerator.cpp:
3824         (JSC::BytecodeGenerator::emitCallForwardArgumentsInTailPosition):
3825         * wasm/js/WebAssemblyFunction.cpp:
3826         (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
3827
3828 2019-04-29  Saam Barati  <sbarati@apple.com>
3829
3830         Make JITType an enum class
3831         https://bugs.webkit.org/show_bug.cgi?id=197394
3832
3833         Reviewed by Yusuke Suzuki.
3834
3835         This makes the code more easily searchable.
3836
3837         * bytecode/CallLinkStatus.cpp:
3838         (JSC::CallLinkStatus::computeFor):
3839         * bytecode/CodeBlock.cpp:
3840         (JSC::CodeBlock::dumpAssumingJITType const):
3841         (JSC::CodeBlock::specialOSREntryBlockOrNull):
3842         (JSC::timeToLive):
3843         (JSC::CodeBlock::propagateTransitions):
3844         (JSC::CodeBlock::baselineAlternative):
3845         (JSC::CodeBlock::baselineVersion):
3846         (JSC::CodeBlock::hasOptimizedReplacement):
3847         (JSC::CodeBlock::noticeIncomingCall):
3848         (JSC::CodeBlock::setOptimizationThresholdBasedOnCompilationResult):
3849         (JSC::CodeBlock::tallyFrequentExitSites):
3850         (JSC::CodeBlock::frameRegisterCount):
3851         (JSC::CodeBlock::bytecodeOffsetFromCallSiteIndex):