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