Web Inspector: Audit: provide a way to get the contents of resources
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2019-03-14  Devin Rousso  <drousso@apple.com>
2
3         Web Inspector: Audit: provide a way to get the contents of resources
4         https://bugs.webkit.org/show_bug.cgi?id=195266
5         <rdar://problem/48550911>
6
7         Reviewed by Joseph Pecoraro.
8
9         * inspector/InjectedScriptBase.cpp:
10         (Inspector::InjectedScriptBase::makeAsyncCall):
11         Drive-by: fix missing `else`.
12
13 2019-03-14  Devin Rousso  <drousso@apple.com>
14
15         Web Inspector: Styles: `::-webkit-scrollbar*` rules aren't shown
16         https://bugs.webkit.org/show_bug.cgi?id=195123
17         <rdar://problem/48450148>
18
19         Reviewed by Joseph Pecoraro.
20
21         * inspector/protocol/CSS.json:
22         Add `CSS.PseudoId` enum, rather than send a number, so that we have more knowledge about
23         which pseudo type the rule corresponds to (e.g. a string is more descriptive than a number).
24
25 2019-03-13  Caio Lima  <ticaiolima@gmail.com>
26
27         [JSC] CodeBlock::visitChildren is reporting extra memory even when its JITCode is singleton
28         https://bugs.webkit.org/show_bug.cgi?id=195638
29
30         Reviewed by Mark Lam.
31
32         This patch introduces a m_isShared flag to track whether the
33         JITCode is shared between many CodeBlocks. This flag is used in
34         `CodeBlock::setJITCode` and `CodeBlock::visitChildren` to avoid
35         reporting duplicated extra memory for singleton JITCodes.
36         With those changes, we now stop counting singleton LLIntEntrypoints
37         as extra memory, since they are declared as static variables. This
38         change can potentially avoid unecessary GC pressure, because
39         extra memory is used by Heap::updateAllocationLimits() to update Heap
40         limits.
41         Even though it is hard to show performance difference for this change
42         (see results below), it is important to keep extra memory usage
43         correct. Otherwise, it can be a source of a complicated bug on
44         GC in the future.
45
46         Results from last run of Speedometer 2 comparing ToT and changes. We
47         collected those numbers running Minibrowser on a MacBook Pro 15-inch
48         with 2,6 GHz Intel Core i7. Both versions are with JIT disabled,
49         since these singleton JITCode are only used by this configuration:
50
51         Speedometer2 Run #1
52             ToT: 58.2 +- 1.1
53             changes: 57.9 +- 0.99
54
55         Speedometer2 Run #2
56             ToT: 58.5 +- 1.7
57             changes: 58.0 +- 1.5
58
59         Speedometer2 Run #2
60             ToT: 58.5 +- 0.99
61             changes: 57.1 +- 1.5
62
63         * bytecode/CodeBlock.cpp:
64         (JSC::CodeBlock::estimatedSize):
65         (JSC::CodeBlock::visitChildren):
66         * bytecode/CodeBlock.h:
67         (JSC::CodeBlock::setJITCode):
68         * jit/JITCode.cpp:
69         (JSC::JITCode::JITCode):
70         (JSC::JITCodeWithCodeRef::JITCodeWithCodeRef):
71         (JSC::DirectJITCode::DirectJITCode):
72         (JSC::NativeJITCode::NativeJITCode):
73         * jit/JITCode.h:
74         (JSC::JITCode::isShared const):
75         * llint/LLIntEntrypoint.cpp:
76         (JSC::LLInt::setFunctionEntrypoint):
77         (JSC::LLInt::setEvalEntrypoint):
78         (JSC::LLInt::setProgramEntrypoint):
79         (JSC::LLInt::setModuleProgramEntrypoint):
80
81 2019-03-13  Keith Rollin  <krollin@apple.com>
82
83         Add support for new StagedFrameworks layout
84         https://bugs.webkit.org/show_bug.cgi?id=195543
85
86         Reviewed by Alexey Proskuryakov.
87
88         When creating the WebKit layout for out-of-band Safari/WebKit updates,
89         use an optional path prefix when called for.
90
91         * Configurations/Base.xcconfig:
92
93 2019-03-13  Mark Lam  <mark.lam@apple.com>
94
95         Remove unneeded --tradeDestructorBlocks option.
96         https://bugs.webkit.org/show_bug.cgi?id=195698
97         <rdar://problem/39681388>
98
99         Reviewed by Yusuke Suzuki.
100
101         There's no reason why we would ever want --tradeDestructorBlocks to be false.
102
103         Also, there was an assertion in BlockDirectory::endMarking() for when
104         (!Options::tradeDestructorBlocks() && needsDestruction()).  This assertion is
105         outdated because the BlockDirectory's m_empty set used to mean the set of all
106         blocks that have no live (as in not reachable by GC) objects and dead objects
107         also do not require destructors to be called on them.  The current meaning of
108         m_empty is that it is the set of all blocks that have no live objects,
109         independent of whether they needs destructors to be called on them or not.
110         The assertion is no longer valid for the new meaning of m_empty as m_empty may
111         now contain destructible blocks.  This assertion is now removed as part of this
112         patch.
113
114         * heap/BlockDirectory.cpp:
115         (JSC::BlockDirectory::endMarking):
116         * heap/LocalAllocator.cpp:
117         (JSC::LocalAllocator::tryAllocateWithoutCollecting):
118         * runtime/Options.h:
119
120 2019-03-13  Dominik Infuehr  <dinfuehr@igalia.com>
121
122         String overflow when using StringBuilder in JSC::createError
123         https://bugs.webkit.org/show_bug.cgi?id=194957
124
125         Reviewed by Mark Lam.
126
127         StringBuilder in notAFunctionSourceAppender didn't check
128         for overflows but just failed.
129
130         * runtime/ExceptionHelpers.cpp:
131         (JSC::notAFunctionSourceAppender):
132
133 2019-03-11  Yusuke Suzuki  <ysuzuki@apple.com>
134
135         [JSC] Move species watchpoint installation from ArrayPrototype to JSGlobalObject
136         https://bugs.webkit.org/show_bug.cgi?id=195593
137
138         Reviewed by Keith Miller.
139
140         This patch moves watchpoints installation and watchpoints themselves from ArrayPrototype to JSGlobalObject because of the following two reasons.
141
142         1. ArrayPrototype configures finalizer because of std::unique_ptr<> for watchpoints. If we move them from ArrayPrototype to JSGlobalObject, we do
143            not need to set finalizer. And we can avoid unnecessary WeakBlock allocation.
144
145         2. This code lazily configures watchpoints instead of setting watchpoints eagerly in JSGlobalObject::init. We would like to expand this mechanism
146            to other watchpoints which are eagerly configured in JSGlobalObject::init. Putting these code in JSGlobalObject instead of scattering them in
147            each XXXPrototype / XXXConstructor can encourage the reuse of the code.
148
149         * runtime/ArrayPrototype.cpp:
150         (JSC::ArrayPrototype::create):
151         (JSC::speciesWatchpointIsValid):
152         (JSC::ArrayPrototype::destroy): Deleted.
153         (JSC::ArrayPrototype::tryInitializeSpeciesWatchpoint): Deleted.
154         (JSC::ArrayPrototypeAdaptiveInferredPropertyWatchpoint::ArrayPrototypeAdaptiveInferredPropertyWatchpoint): Deleted.
155         (JSC::ArrayPrototypeAdaptiveInferredPropertyWatchpoint::handleFire): Deleted.
156         * runtime/ArrayPrototype.h:
157         * runtime/JSGlobalObject.cpp:
158         (JSC::JSGlobalObject::tryInstallArraySpeciesWatchpoint): Instead of using ArrayPrototypeAdaptiveInferredPropertyWatchpoint,
159         we use ObjectPropertyChangeAdaptiveWatchpoint. We create watchpoints after touching WatchpointSet since ObjectPropertyChangeAdaptiveWatchpoint
160         requires WatchpointSet is IsWatched state.
161         * runtime/JSGlobalObject.h:
162
163 2019-03-12  Yusuke Suzuki  <ysuzuki@apple.com>
164
165         [JSC] OSR entry should respect abstract values in addition to flush formats
166         https://bugs.webkit.org/show_bug.cgi?id=195653
167
168         Reviewed by Mark Lam.
169
170         Let's consider the following graph.
171
172         Block #0
173             ...
174             27:< 2:loc13> JSConstant(JS|UseAsOther, StringIdent, Strong:String (atomic) (identifier): , StructureID: 42679, bc#10, ExitValid)
175             ...
176             28:< 2:loc13> ArithPow(DoubleRep:@437<Double>, Int32:@27, Double|UseAsOther, BytecodeDouble, Exits, bc#10, ExitValid)
177             29:<!0:->     MovHint(DoubleRep:@28<Double>, MustGen, loc7, W:SideState, ClobbersExit, bc#10, ExitValid)
178             30:< 1:->     SetLocal(DoubleRep:@28<Double>, loc7(M<Double>/FlushedDouble), machine:loc6, W:Stack(-8), bc#10, exit: bc#14, ExitValid)  predicting BytecodeDouble
179             ...
180             73:<!0:->     Jump(MustGen, T:#1, W:SideState, bc#71, ExitValid)
181
182         Block #1 (bc#71): (OSR target) pred, #0
183             ...
184            102:<!2:loc15> GetLocal(Check:Untyped:@400, Double|MustGen|PureInt, BytecodeDouble, loc7(M<Double>/FlushedDouble), machine:loc6, R:Stack(-8), bc#120, ExitValid)  predicting BytecodeDouble
185             ...
186
187         CFA at @28 says it is invalid since there are type contradiction (Int32:@27 v.s. StringIdent). So, of course, we do not propagate #0's type information to #1 since we become invalid state.
188         However, #1 is still reachable since it is an OSR target. Since #0 was only the predecessor of #1, loc7's type information becomes None at the head of #1.
189         Since loc7's AbstractValue is None, @102 GetLocal emits breakpoint. It is OK as long as OSR entry fails because AbstractValue validation requires the given value is None type.
190
191         The issue here is that we skipped AbstractValue validation when we have FlushFormat information. Since loc7 has FlushedDouble format, DFG OSR entry code does not validate it against AbstractValue,
192         which is None. Then, we hit the breakpoint emitted by @102.
193
194         This patch performs AbstractValue validation against values even if we have FlushFormat. We should correctly configure AbstractValue for OSR entry's locals too to avoid unnecessary OSR entry
195         failures in the future but anyway validating locals with AbstractValue is correct behavior here since DFGSpeculativeJIT relies on that.
196
197         * dfg/DFGOSREntry.cpp:
198         (JSC::DFG::prepareOSREntry):
199
200 2019-03-12  Michael Saboff  <msaboff@apple.com>
201
202         REGRESSION (iOS 12.2): Webpage using CoffeeScript crashes
203         https://bugs.webkit.org/show_bug.cgi?id=195613
204
205         Reviewed by Mark Lam.
206
207         The bug here is in Yarr JIT backreference matching code.  We are incorrectly
208         using a checkedOffset / inputPosition correction when checking for the available
209         length left in a string.  It is improper to do these corrections as a backreference's
210         match length is based on what was matched in the referenced capture group and not
211         part of the checkedOffset and inputPosition computed when we compiled the RegExp.
212         In some cases, the resulting incorrect calculation would allow us to go past
213         the subject string's length.  Removed these adjustments.
214
215         After writing tests for the first bug, found another bug where the non-greedy
216         backreference backtracking code didn't do an "are we at the end of the input?" check.
217         This caused an infinite loop as we'd jump from the backtracking code back to
218         try matching one more backreference, fail and then backtrack.
219
220         * yarr/YarrJIT.cpp:
221         (JSC::Yarr::YarrGenerator::generateBackReference):
222         (JSC::Yarr::YarrGenerator::backtrackBackReference):
223
224 2019-03-12  Robin Morisset  <rmorisset@apple.com>
225
226         A lot more classes have padding that can be reduced by reordering their fields
227         https://bugs.webkit.org/show_bug.cgi?id=195579
228
229         Reviewed by Mark Lam.
230
231         * assembler/LinkBuffer.h:
232         * dfg/DFGArrayifySlowPathGenerator.h:
233         (JSC::DFG::ArrayifySlowPathGenerator::ArrayifySlowPathGenerator):
234         * dfg/DFGCallArrayAllocatorSlowPathGenerator.h:
235         (JSC::DFG::CallArrayAllocatorSlowPathGenerator::CallArrayAllocatorSlowPathGenerator):
236         (JSC::DFG::CallArrayAllocatorWithVariableSizeSlowPathGenerator::CallArrayAllocatorWithVariableSizeSlowPathGenerator):
237         * dfg/DFGGraph.h:
238         * dfg/DFGNode.h:
239         (JSC::DFG::SwitchData::SwitchData):
240         * dfg/DFGPlan.cpp:
241         (JSC::DFG::Plan::Plan):
242         * dfg/DFGPlan.h:
243         * dfg/DFGSlowPathGenerator.h:
244         (JSC::DFG::CallSlowPathGenerator::CallSlowPathGenerator):
245         * dfg/DFGSpeculativeJIT.cpp:
246         (JSC::DFG::SpeculativeJIT::SpeculativeJIT):
247         * dfg/DFGSpeculativeJIT.h:
248         * domjit/DOMJITSignature.h:
249         (JSC::DOMJIT::Signature::Signature):
250         (JSC::DOMJIT::Signature::effect):
251         (JSC::DOMJIT::Signature::argumentCount): Deleted.
252         * heap/MarkingConstraintSolver.h:
253         * heap/SlotVisitor.h:
254         * jit/CallFrameShuffleData.h:
255         * jit/JITDivGenerator.h:
256         * jit/SpillRegistersMode.h:
257         * parser/Nodes.h:
258         * profiler/ProfilerOSRExit.cpp:
259         (JSC::Profiler::OSRExit::OSRExit):
260         * profiler/ProfilerOSRExit.h:
261         * runtime/ArrayBufferView.h:
262         * runtime/SamplingProfiler.cpp:
263         (JSC::SamplingProfiler::SamplingProfiler):
264         * runtime/SamplingProfiler.h:
265         * runtime/TypeSet.cpp:
266         (JSC::StructureShape::StructureShape):
267         * runtime/TypeSet.h:
268         * runtime/Watchdog.h:
269
270 2019-03-12  Mark Lam  <mark.lam@apple.com>
271
272         The HasIndexedProperty node does GC.
273         https://bugs.webkit.org/show_bug.cgi?id=195559
274         <rdar://problem/48767923>
275
276         Reviewed by Yusuke Suzuki.
277
278         HasIndexedProperty can call the slow path operationHasIndexedPropertyByInt(),
279         which can eventually call JSString::getIndex(), which can resolve a rope.
280
281         * dfg/DFGDoesGC.cpp:
282         (JSC::DFG::doesGC):
283
284 2019-03-12  Devin Rousso  <drousso@apple.com>
285
286         Web Inspector: Audit: there should be a centralized place for reusable code
287         https://bugs.webkit.org/show_bug.cgi?id=195265
288         <rdar://problem/47040673>
289
290         Reviewed by Joseph Pecoraro.
291
292         * inspector/protocol/Audit.json:
293         Increment version.
294
295 2019-03-12  Robin Morisset  <rmorisset@apple.com>
296
297         blocksInPreOrder and blocksInPostOrder should reserve the right capacity for their result vector
298         https://bugs.webkit.org/show_bug.cgi?id=195595
299
300         Reviewed by Saam Barati.
301
302         Also change BlockList from being Vector<BasicBlock*, 5> to Vector<BasicBlock*>
303
304         * dfg/DFGBasicBlock.h:
305         * dfg/DFGGraph.cpp:
306         (JSC::DFG::Graph::blocksInPreOrder):
307         (JSC::DFG::Graph::blocksInPostOrder):
308
309 2019-03-11  Ross Kirsling  <ross.kirsling@sony.com>
310
311         Add Optional to Forward.h.
312         https://bugs.webkit.org/show_bug.cgi?id=195586
313
314         Reviewed by Darin Adler.
315
316         * b3/B3Common.cpp:
317         * b3/B3Common.h:
318         * debugger/DebuggerParseData.cpp:
319         * debugger/DebuggerParseData.h:
320         * heap/HeapSnapshot.cpp:
321         * heap/HeapSnapshot.h:
322         * jit/PCToCodeOriginMap.cpp:
323         * jit/PCToCodeOriginMap.h:
324         * runtime/AbstractModuleRecord.cpp:
325         * runtime/AbstractModuleRecord.h:
326         * wasm/WasmInstance.h:
327         * wasm/WasmModuleParser.h:
328         * wasm/WasmSectionParser.cpp:
329         * wasm/WasmSectionParser.h:
330         * wasm/WasmStreamingParser.cpp:
331         * wasm/WasmStreamingParser.h:
332         * yarr/YarrFlags.cpp:
333         * yarr/YarrFlags.h:
334         * yarr/YarrUnicodeProperties.cpp:
335         * yarr/YarrUnicodeProperties.h:
336         Remove unnecessary includes from headers.
337
338 2019-03-11  Justin Fan  <justin_fan@apple.com>
339
340         [Web GPU] Update GPUSwapChainDescriptor, GPUSwapChain and implement GPUCanvasContext
341         https://bugs.webkit.org/show_bug.cgi?id=194406
342         <rdar://problem/47892466>
343
344         Reviewed by Myles C. Maxfield.
345
346         Added WebGPU to inspector context types.
347
348         * inspector/protocol/Canvas.json:
349         * inspector/scripts/codegen/generator.py:
350
351 2019-03-11  Yusuke Suzuki  <ysuzuki@apple.com>
352
353         [JSC] Reduce # of structures in JSGlobalObject initialization
354         https://bugs.webkit.org/show_bug.cgi?id=195498
355
356         Reviewed by Darin Adler.
357
358         This patch reduces # of structure allocations in JSGlobalObject initialization. Now it becomes 141, it fits in one
359         MarkedBlock and this patch drops one MarkedBlock used for Structure previously.
360
361         * CMakeLists.txt:
362         * DerivedSources-output.xcfilelist:
363         * DerivedSources.make:
364         * JavaScriptCore.xcodeproj/project.pbxproj:
365         * runtime/ArrayIteratorPrototype.cpp:
366         (JSC::ArrayIteratorPrototype::finishCreation): ArrayIteratorPrototype, MapIteratorPrototype, and StringIteratorPrototype's
367         "next" properties are referenced by JSGlobalObject::init, and it causes reification of the lazy "next" property and structure
368         transition anyway. So we should put it eagerly "without-transition" configuration to avoid one structure transition.
369
370         * runtime/ArrayPrototype.cpp:
371         (JSC::ArrayPrototype::finishCreation): @@unscopable object's structure should be dictionary because (1) it is used as a dictionary
372         in with-scope-resolution and (2) since with-scope-resolution is C++ runtime function anyway, non-dictionary structure does not add
373         any performance benefit. This change saves several structures that are not useful.
374
375         * runtime/ClonedArguments.cpp:
376         (JSC::ClonedArguments::createStructure): Bake CloneArguments's structure with 'without-transition' manner.
377
378         * runtime/JSGlobalObject.cpp:
379         (JSC::JSGlobalObject::init): Previously we are always call resetProtoype at the end of JSGlobalObject::init. But it is not necessary
380         since we do not change [[Prototype]] of JSGlobalObject. All we want is (1) fixupPrototypeChainWithObjectPrototype's operation and (2) setGlobalThis
381         operation. Since setGlobalThis part is done in JSGlobalObject::finishCreation, fixupPrototypeChainWithObjectPrototype is only the thing
382         we should do here.
383
384         (JSC::JSGlobalObject::fixupPrototypeChainWithObjectPrototype):
385         (JSC::JSGlobalObject::resetPrototype): If the [[Prototype]] is the same to the current [[Prototype]], we can skip the operation.
386
387         * runtime/JSGlobalObject.h:
388         * runtime/MapIteratorPrototype.cpp:
389         (JSC::MapIteratorPrototype::finishCreation):
390         * runtime/NullGetterFunction.h:
391         * runtime/NullSetterFunction.h: Since structures of them are allocated per JSGlobalObject and they are per-JSGlobalObject,
392         we can use without-transition property addition.
393
394         * runtime/StringIteratorPrototype.cpp:
395         (JSC::StringIteratorPrototype::finishCreation):
396         * runtime/VM.cpp:
397         (JSC::VM::VM):
398         (JSC::VM::setIteratorStructureSlow):
399         (JSC::VM::mapIteratorStructureSlow): These structures are only used in WebCore's main thread.
400         * runtime/VM.h:
401         (JSC::VM::setIteratorStructure):
402         (JSC::VM::mapIteratorStructure):
403
404 2019-03-08  Yusuke Suzuki  <ysuzuki@apple.com>
405
406         [JSC] BuiltinExecutables should behave like a WeakSet instead of generic WeakHandleOwner for memory footprint
407         https://bugs.webkit.org/show_bug.cgi?id=195508
408
409         Reviewed by Darin Adler.
410
411         Weak<> is not cheap in terms of memory footprint. We allocate WeakBlock (256 bytes) for book-keeping Weak<>.
412         Currently BuiltinExecutables has 203 Weak<> members and many WeakBlocks are actually allocated because
413         many UnlinkedFunctionExecutables in BuiltinExecutables are allocated during JSGlobalObject initialization process.
414
415         This patch changes two things in BuiltinExecutables.
416
417         1. Previously we have m_xxxSourceCode fields too. But we do not need to keep it since we know how to produce it when it is required.
418            We generate SourceCode in xxxSourceCode() method instead of just returning m_xxxSourceCode. This reduces sizeof(BuiltinExecutables) 24 x 203 = 4KB.
419
420         2. Instead of using Weak<>, BuiltinExecutables holds raw array of UnlinkedFunctionExecutable*. And Heap::finalizeUnconditionalFinalizers() correctly clears dead executables.
421            This is similar to JSWeakSet implementation. And it saves WeakBlock allocations.
422
423         * builtins/BuiltinExecutables.cpp:
424         (JSC::BuiltinExecutables::BuiltinExecutables):
425         (JSC::BuiltinExecutables::finalizeUnconditionally):
426         (JSC::JSC_FOREACH_BUILTIN_CODE): Deleted.
427         (JSC::BuiltinExecutables::finalize): Deleted.
428         * builtins/BuiltinExecutables.h:
429         (JSC::BuiltinExecutables::static_cast<unsigned>):
430         (): Deleted.
431         * heap/Heap.cpp:
432         (JSC::Heap::finalizeUnconditionalFinalizers):
433
434 2019-03-11  Robin Morisset  <rmorisset@apple.com>
435
436         IntlDateTimeFormat can be shrunk by 32 bytes
437         https://bugs.webkit.org/show_bug.cgi?id=195504
438
439         Reviewed by Darin Adler.
440
441         * runtime/IntlDateTimeFormat.h:
442
443 2019-03-11  Robin Morisset  <rmorisset@apple.com>
444
445         IntlCollator can be shrunk by 16 bytes
446         https://bugs.webkit.org/show_bug.cgi?id=195503
447
448         Reviewed by Darin Adler.
449
450         * runtime/IntlCollator.h:
451
452 2019-03-11  Robin Morisset  <rmorisset@apple.com>
453
454         IntlNumberFormat can be shrunk by 16 bytes
455         https://bugs.webkit.org/show_bug.cgi?id=195505
456
457         Reviewed by Darin Adler.
458
459         * runtime/IntlNumberFormat.h:
460
461 2019-03-11  Caio Lima  <ticaiolima@gmail.com>
462
463         [ESNext][BigInt] Implement "~" unary operation
464         https://bugs.webkit.org/show_bug.cgi?id=182216
465
466         Reviewed by Keith Miller.
467
468         This patch is adding support of BigInt into op_bitnot operations. In
469         addition, we are changing ArithBitNot to handle only Number operands,
470         while introducing a new node named ValueBitNot to handle Untyped and
471         BigInt. This node follows the same approach we are doing into other
472         arithimetic operations into DFG.
473
474         * dfg/DFGAbstractInterpreterInlines.h:
475         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
476
477         It is possible that fixup and prediction propagation don't convert a
478         ValueBitNot(ConstInt32) into ArithBitNot(ConstInt32) because these
479         analysis are conservative. In such case, we are adding constant
480         folding rules to ValueBitNot AI.
481
482         * dfg/DFGBackwardsPropagationPhase.cpp:
483         (JSC::DFG::BackwardsPropagationPhase::propagate):
484
485         ValueBitNot has same rules as ArithBitNot on backwards propagation.
486
487         * dfg/DFGByteCodeParser.cpp:
488         (JSC::DFG::ByteCodeParser::parseBlock):
489
490         We can emit ArithBitNot if we know that operand of op_bitnot is a
491         Number or any int. Otherwise we fallback to ValueBitNot and rely on
492         fixup to convert the node to ArithBitNot when it is possible.
493         ValueBitNot uses heap prediction on prediction propagation and we
494         collect its type from op_bitnot's value profiler.
495
496         * dfg/DFGClobberize.h:
497         (JSC::DFG::clobberize):
498
499         When we have the case with ValueBitNot(BigInt), we don't clobberize
500         world.
501
502         * dfg/DFGDoesGC.cpp:
503         (JSC::DFG::doesGC):
504
505         ValueBitNot can GC on BigIntUse because, right now, all bitNot
506         operation allocates temporary BigInts to perform calculations and it
507         can potentially trigger GC.
508
509         * dfg/DFGFixupPhase.cpp:
510         (JSC::DFG::FixupPhase::fixupNode):
511
512         ValueBitNot is responsible do handle BigIntUse and UntypedUse. To all
513         other uses, we fallback to ArithBitNot.
514
515         * dfg/DFGNode.h:
516         (JSC::DFG::Node::hasHeapPrediction):
517         * dfg/DFGNodeType.h:
518         * dfg/DFGOperations.cpp:
519         (JSC::DFG::bitwiseBinaryOp):
520
521         This template function is abstracting the new semantics of numeric
522         values operations on bitwise operations. These operations usually
523         folow these steps:
524
525             1. rhsNumeric = GetInt32OrBigInt(rhs)
526             2. lhsNumeric = GetInt32OrBigInt(lhs)
527             3. trhow error if TypeOf(rhsNumeric) != TypeOf(lhsNumeric)
528             4. return BigInt::bitwiseOp(bitOp, rhs, lhs) if TypeOf(lhsNumeric) == BigInt
529             5. return rhs <int32BitOp> lhs
530
531         Since we have almost the same code for every bitwise op,
532         we use such template to avoid code duplication. The template receives
533         Int32 and BigInt operations as parameter. Error message is received as
534         `const char*` instead of `String&` to avoid String allocation even when
535         there is no error to throw.
536
537         * dfg/DFGOperations.h:
538         * dfg/DFGPredictionPropagationPhase.cpp:
539         * dfg/DFGSafeToExecute.h:
540         (JSC::DFG::safeToExecute):
541         * dfg/DFGSpeculativeJIT.cpp:
542         (JSC::DFG::SpeculativeJIT::compileValueBitNot):
543
544         ValueBitNot generates speculative code for BigIntUse and this code is a
545         call to `operationBitNotBigInt`. This operation is faster than
546         `operationValueBitNot` because there is no need to check types of
547         operands and execute properly operation. We still need to check
548         exceptions after `operationBitNotBigInt` because it can throw OOM.
549
550         (JSC::DFG::SpeculativeJIT::compileBitwiseNot):
551         * dfg/DFGSpeculativeJIT.h:
552         * dfg/DFGSpeculativeJIT32_64.cpp:
553         (JSC::DFG::SpeculativeJIT::compile):
554         * dfg/DFGSpeculativeJIT64.cpp:
555         (JSC::DFG::SpeculativeJIT::compile):
556         * ftl/FTLCapabilities.cpp:
557         (JSC::FTL::canCompile):
558         * ftl/FTLLowerDFGToB3.cpp:
559         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
560         (JSC::FTL::DFG::LowerDFGToB3::compileValueBitNot):
561         (JSC::FTL::DFG::LowerDFGToB3::compileArithBitNot):
562         * runtime/CommonSlowPaths.cpp:
563         (JSC::SLOW_PATH_DECL):
564         * runtime/JSBigInt.cpp:
565         (JSC::JSBigInt::bitwiseNot):
566         * runtime/JSBigInt.h:
567
568 2019-03-11  Darin Adler  <darin@apple.com>
569
570         Specify fixed precision explicitly to prepare to change String::number and StringBuilder::appendNumber floating point behavior
571         https://bugs.webkit.org/show_bug.cgi?id=195533
572
573         Reviewed by Brent Fulgham.
574
575         * API/tests/ExecutionTimeLimitTest.cpp:
576         (testExecutionTimeLimit): Use appendFixedPrecisionNumber.
577         * runtime/NumberPrototype.cpp:
578         (JSC::numberProtoFuncToPrecision): Use numberToStringFixedPrecision.
579         * runtime/Options.cpp:
580         (JSC::Option::dump const): Use appendFixedPrecisionNumber.
581
582 2019-03-10  Ross Kirsling  <ross.kirsling@sony.com>
583
584         Invalid flags in a RegExp literal should be an early SyntaxError
585         https://bugs.webkit.org/show_bug.cgi?id=195514
586
587         Reviewed by Darin Adler.
588
589         Currently we're throwing a *runtime* SyntaxError; this should occur at parse time. 
590
591           12.2.8.1 Static Semantics: Early Errors
592             PrimaryExpression : RegularExpressionLiteral
593               - It is a Syntax Error if BodyText of RegularExpressionLiteral cannot be recognized
594                 using the goal symbol Pattern of the ECMAScript RegExp grammar specified in 21.2.1.
595               - It is a Syntax Error if FlagText of RegularExpressionLiteral contains any code points
596                 other than "g", "i", "m",  "s", "u", or "y", or if it contains the same code point more than once.
597
598         In fixing this, let's also move flag handling from runtime/ to yarr/.
599
600         * yarr/YarrSyntaxChecker.cpp:
601         (JSC::Yarr::checkSyntax):
602         Check flags before checking pattern.
603
604         * CMakeLists.txt:
605         * JavaScriptCore.xcodeproj/project.pbxproj:
606         * Sources.txt:
607         * bytecompiler/NodesCodegen.cpp:
608         (JSC::RegExpNode::emitBytecode):
609         * inspector/ContentSearchUtilities.cpp:
610         (Inspector::ContentSearchUtilities::findMagicComment):
611         * runtime/CachedTypes.cpp:
612         * runtime/RegExp.cpp:
613         (JSC::RegExp::RegExp):
614         (JSC::RegExp::createWithoutCaching):
615         (JSC::RegExp::create):
616         (JSC::regExpFlags): Deleted.
617         * runtime/RegExp.h:
618         * runtime/RegExpCache.cpp:
619         (JSC::RegExpCache::lookupOrCreate):
620         (JSC::RegExpCache::ensureEmptyRegExpSlow):
621         * runtime/RegExpCache.h:
622         * runtime/RegExpConstructor.cpp:
623         (JSC::toFlags):
624         (JSC::regExpCreate):
625         (JSC::constructRegExp):
626         * runtime/RegExpKey.h:
627         (JSC::RegExpKey::RegExpKey):
628         (WTF::HashTraits<JSC::RegExpKey>::constructDeletedValue):
629         (WTF::HashTraits<JSC::RegExpKey>::isDeletedValue):
630         (): Deleted.
631         * runtime/RegExpPrototype.cpp:
632         (JSC::regExpProtoFuncCompile):
633         * testRegExp.cpp:
634         (parseRegExpLine):
635         * yarr/RegularExpression.cpp:
636         (JSC::Yarr::RegularExpression::Private::compile):
637         * yarr/YarrFlags.cpp: Added.
638         (JSC::Yarr::parseFlags):
639         * yarr/YarrFlags.h: Added.
640         * yarr/YarrInterpreter.h:
641         (JSC::Yarr::BytecodePattern::ignoreCase const):
642         (JSC::Yarr::BytecodePattern::multiline const):
643         (JSC::Yarr::BytecodePattern::sticky const):
644         (JSC::Yarr::BytecodePattern::unicode const):
645         (JSC::Yarr::BytecodePattern::dotAll const):
646         * yarr/YarrPattern.cpp:
647         (JSC::Yarr::YarrPattern::compile):
648         (JSC::Yarr::YarrPattern::YarrPattern):
649         (JSC::Yarr::YarrPattern::dumpPattern):
650         * yarr/YarrPattern.h:
651         (JSC::Yarr::YarrPattern::global const):
652         (JSC::Yarr::YarrPattern::ignoreCase const):
653         (JSC::Yarr::YarrPattern::multiline const):
654         (JSC::Yarr::YarrPattern::sticky const):
655         (JSC::Yarr::YarrPattern::unicode const):
656         (JSC::Yarr::YarrPattern::dotAll const):
657         Move flag handling to Yarr and modernize API.
658
659 2019-03-09  Robin Morisset  <rmorisset@apple.com>
660
661         Compilation can be shrunk by 8 bytes
662         https://bugs.webkit.org/show_bug.cgi?id=195500
663
664         Reviewed by Mark Lam.
665
666         * profiler/ProfilerCompilation.cpp:
667         (JSC::Profiler::Compilation::Compilation):
668         * profiler/ProfilerCompilation.h:
669
670 2019-03-09  Robin Morisset  <rmorisset@apple.com>
671
672         BinarySwitch can be shrunk by 8 bytes
673         https://bugs.webkit.org/show_bug.cgi?id=195493
674
675         Reviewed by Mark Lam.
676
677         * jit/BinarySwitch.cpp:
678         (JSC::BinarySwitch::BinarySwitch):
679         * jit/BinarySwitch.h:
680
681 2019-03-09  Robin Morisset  <rmorisset@apple.com>
682
683         AsyncStackTrace can be shrunk by 8 bytes
684         https://bugs.webkit.org/show_bug.cgi?id=195491
685
686         Reviewed by Mark Lam.
687
688         * inspector/AsyncStackTrace.h:
689
690 2019-03-08  Mark Lam  <mark.lam@apple.com>
691
692         Stack overflow crash in JSC::JSObject::hasInstance.
693         https://bugs.webkit.org/show_bug.cgi?id=195458
694         <rdar://problem/48710195>
695
696         Reviewed by Yusuke Suzuki.
697
698         * runtime/JSObject.cpp:
699         (JSC::JSObject::hasInstance):
700
701 2019-03-08  Robin Morisset  <rmorisset@apple.com>
702
703         IntegerCheckCombiningPhase::Range can be shrunk by 8 bytes
704         https://bugs.webkit.org/show_bug.cgi?id=195487
705
706         Reviewed by Saam Barati.
707
708         * dfg/DFGIntegerCheckCombiningPhase.cpp:
709
710 2019-03-08  Robin Morisset  <rmorisset@apple.com>
711
712         TypeLocation can be shrunk by 8 bytes
713         https://bugs.webkit.org/show_bug.cgi?id=195483
714
715         Reviewed by Mark Lam.
716
717         * bytecode/TypeLocation.h:
718         (JSC::TypeLocation::TypeLocation):
719
720 2019-03-08  Robin Morisset  <rmorisset@apple.com>
721
722         GetByIdStatus can be shrunk by 16 bytes
723         https://bugs.webkit.org/show_bug.cgi?id=195480
724
725         Reviewed by Saam Barati.
726
727         8 bytes from reordering fields
728         8 more bytes by making the enum State only use 1 byte.
729
730         * bytecode/GetByIdStatus.cpp:
731         (JSC::GetByIdStatus::GetByIdStatus):
732         * bytecode/GetByIdStatus.h:
733
734 2019-03-08  Robin Morisset  <rmorisset@apple.com>
735
736         PutByIdVariant can be shrunk by 8 bytes
737         https://bugs.webkit.org/show_bug.cgi?id=195482
738
739         Reviewed by Mark Lam.
740
741         * bytecode/PutByIdVariant.h:
742         (JSC::PutByIdVariant::PutByIdVariant):
743
744 2019-03-08  Yusuke Suzuki  <ysuzuki@apple.com>
745
746         Unreviewed, follow-up after r242568
747
748         Robin pointed that calculation of `numberOfChildren` and `nonEmptyIndex` is unnecessary.
749
750         * dfg/DFGAbstractInterpreterInlines.h:
751         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
752
753 2019-03-08  Yusuke Suzuki  <ysuzuki@apple.com>
754
755         [JSC] We should have more WithoutTransition functions which are usable for JSGlobalObject initialization
756         https://bugs.webkit.org/show_bug.cgi?id=195447
757
758         Reviewed by Filip Pizlo.
759
760         This patch reduces # of unnecessary structure transitions in JSGlobalObject initialization to avoid unnecessary allocations
761         caused by Structure transition. One example is WeakBlock allocation for StructureTransitionTable.
762         To achieve this, we (1) add putDirectNonIndexAccessorWithoutTransition and putDirectNativeIntrinsicGetterWithoutTransition
763         to add accessor properties without transition, and (2) add NameAdditionMode::WithoutStructureTransition mode to InternalFunction::finishCreation
764         to use `putDirectWithoutTransition` instead of `putDirect`.
765
766         * inspector/JSInjectedScriptHostPrototype.cpp:
767         (Inspector::JSInjectedScriptHostPrototype::finishCreation):
768         * inspector/JSJavaScriptCallFramePrototype.cpp:
769         (Inspector::JSJavaScriptCallFramePrototype::finishCreation):
770         * runtime/ArrayConstructor.cpp:
771         (JSC::ArrayConstructor::finishCreation):
772         * runtime/AsyncFunctionConstructor.cpp:
773         (JSC::AsyncFunctionConstructor::finishCreation):
774         * runtime/AsyncGeneratorFunctionConstructor.cpp:
775         (JSC::AsyncGeneratorFunctionConstructor::finishCreation):
776         * runtime/BigIntConstructor.cpp:
777         (JSC::BigIntConstructor::finishCreation):
778         * runtime/BooleanConstructor.cpp:
779         (JSC::BooleanConstructor::finishCreation):
780         * runtime/DateConstructor.cpp:
781         (JSC::DateConstructor::finishCreation):
782         * runtime/ErrorConstructor.cpp:
783         (JSC::ErrorConstructor::finishCreation):
784         * runtime/FunctionConstructor.cpp:
785         (JSC::FunctionConstructor::finishCreation):
786         * runtime/FunctionPrototype.cpp:
787         (JSC::FunctionPrototype::finishCreation):
788         (JSC::FunctionPrototype::addFunctionProperties):
789         (JSC::FunctionPrototype::initRestrictedProperties):
790         * runtime/FunctionPrototype.h:
791         * runtime/GeneratorFunctionConstructor.cpp:
792         (JSC::GeneratorFunctionConstructor::finishCreation):
793         * runtime/InternalFunction.cpp:
794         (JSC::InternalFunction::finishCreation):
795         * runtime/InternalFunction.h:
796         * runtime/IntlCollatorConstructor.cpp:
797         (JSC::IntlCollatorConstructor::finishCreation):
798         * runtime/IntlDateTimeFormatConstructor.cpp:
799         (JSC::IntlDateTimeFormatConstructor::finishCreation):
800         * runtime/IntlNumberFormatConstructor.cpp:
801         (JSC::IntlNumberFormatConstructor::finishCreation):
802         * runtime/IntlPluralRulesConstructor.cpp:
803         (JSC::IntlPluralRulesConstructor::finishCreation):
804         * runtime/JSArrayBufferConstructor.cpp:
805         (JSC::JSGenericArrayBufferConstructor<sharingMode>::finishCreation):
806         * runtime/JSArrayBufferPrototype.cpp:
807         (JSC::JSArrayBufferPrototype::finishCreation):
808         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
809         (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::finishCreation):
810         * runtime/JSGlobalObject.cpp:
811         (JSC::JSGlobalObject::init):
812         * runtime/JSObject.cpp:
813         (JSC::JSObject::putDirectNonIndexAccessorWithoutTransition):
814         (JSC::JSObject::putDirectNativeIntrinsicGetterWithoutTransition):
815         * runtime/JSObject.h:
816         * runtime/JSPromiseConstructor.cpp:
817         (JSC::JSPromiseConstructor::finishCreation):
818         * runtime/JSTypedArrayViewConstructor.cpp:
819         (JSC::JSTypedArrayViewConstructor::finishCreation):
820         * runtime/JSTypedArrayViewPrototype.cpp:
821         (JSC::JSTypedArrayViewPrototype::finishCreation):
822         * runtime/MapConstructor.cpp:
823         (JSC::MapConstructor::finishCreation):
824         * runtime/MapPrototype.cpp:
825         (JSC::MapPrototype::finishCreation):
826         * runtime/NativeErrorConstructor.cpp:
827         (JSC::NativeErrorConstructorBase::finishCreation):
828         * runtime/NullGetterFunction.h:
829         * runtime/NullSetterFunction.h:
830         * runtime/NumberConstructor.cpp:
831         (JSC::NumberConstructor::finishCreation):
832         * runtime/ObjectConstructor.cpp:
833         (JSC::ObjectConstructor::finishCreation):
834         * runtime/ProxyConstructor.cpp:
835         (JSC::ProxyConstructor::finishCreation):
836         * runtime/RegExpConstructor.cpp:
837         (JSC::RegExpConstructor::finishCreation):
838         * runtime/RegExpPrototype.cpp:
839         (JSC::RegExpPrototype::finishCreation):
840         * runtime/SetConstructor.cpp:
841         (JSC::SetConstructor::finishCreation):
842         * runtime/SetPrototype.cpp:
843         (JSC::SetPrototype::finishCreation):
844         * runtime/StringConstructor.cpp:
845         (JSC::StringConstructor::finishCreation):
846         * runtime/SymbolConstructor.cpp:
847         (JSC::SymbolConstructor::finishCreation):
848         * runtime/WeakMapConstructor.cpp:
849         (JSC::WeakMapConstructor::finishCreation):
850         * runtime/WeakSetConstructor.cpp:
851         (JSC::WeakSetConstructor::finishCreation):
852         * wasm/js/WebAssemblyCompileErrorConstructor.cpp:
853         (JSC::WebAssemblyCompileErrorConstructor::finishCreation):
854         * wasm/js/WebAssemblyInstanceConstructor.cpp:
855         (JSC::WebAssemblyInstanceConstructor::finishCreation):
856         * wasm/js/WebAssemblyLinkErrorConstructor.cpp:
857         (JSC::WebAssemblyLinkErrorConstructor::finishCreation):
858         * wasm/js/WebAssemblyMemoryConstructor.cpp:
859         (JSC::WebAssemblyMemoryConstructor::finishCreation):
860         * wasm/js/WebAssemblyModuleConstructor.cpp:
861         (JSC::WebAssemblyModuleConstructor::finishCreation):
862         * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
863         (JSC::WebAssemblyRuntimeErrorConstructor::finishCreation):
864         * wasm/js/WebAssemblyTableConstructor.cpp:
865         (JSC::WebAssemblyTableConstructor::finishCreation):
866
867 2019-03-08  Tadeu Zagallo  <tzagallo@apple.com>
868
869         op_check_tdz does not def its argument
870         https://bugs.webkit.org/show_bug.cgi?id=192880
871         <rdar://problem/46221598>
872
873         Reviewed by Saam Barati.
874
875         This prevented the for-in loop optimization in the bytecode generator, since
876         the analysis sees a redefinition of the loop variable.
877
878         * bytecode/BytecodeUseDef.h:
879         (JSC::computeDefsForBytecodeOffset):
880
881 2019-03-07  Yusuke Suzuki  <ysuzuki@apple.com>
882
883         [JSC] Make more fields lazy in JSGlobalObject
884         https://bugs.webkit.org/show_bug.cgi?id=195449
885
886         Reviewed by Mark Lam.
887
888         This patch makes more fields lazy-allocated in JSGlobalObject to save memory.
889
890         1. Some minor structures like moduleRecordStructure.
891         2. Some functions like parseInt / parseFloat. While they are eagerly created in JIT mode anyway to materialize NumberConstructor, we can lazily allocate them in non JIT mode.
892         3. ArrayBuffer constructor. While it is eagerly allocated in WebCore, we can make lazily allocated in JSC.
893
894         * interpreter/Interpreter.cpp:
895         (JSC::Interpreter::execute):
896         * runtime/JSArrayBufferPrototype.h:
897         * runtime/JSGlobalObject.cpp:
898         (JSC::JSGlobalObject::init):
899         (JSC::JSGlobalObject::visitChildren):
900         * runtime/JSGlobalObject.h:
901         (JSC::JSGlobalObject::parseIntFunction const):
902         (JSC::JSGlobalObject::parseFloatFunction const):
903         (JSC::JSGlobalObject::evalFunction const):
904         (JSC::JSGlobalObject::strictEvalActivationStructure const):
905         (JSC::JSGlobalObject::moduleRecordStructure const):
906         (JSC::JSGlobalObject::moduleNamespaceObjectStructure const):
907         (JSC::JSGlobalObject::proxyObjectStructure const):
908         (JSC::JSGlobalObject::callableProxyObjectStructure const):
909         (JSC::JSGlobalObject::proxyRevokeStructure const):
910         (JSC::JSGlobalObject::arrayBufferConstructor const):
911         (JSC::JSGlobalObject::arrayBufferPrototype const):
912         (JSC::JSGlobalObject::arrayBufferStructure const):
913         * runtime/ProxyObject.h:
914         * runtime/StrictEvalActivation.cpp:
915         (JSC::StrictEvalActivation::StrictEvalActivation):
916         * runtime/StrictEvalActivation.h:
917         * wasm/js/JSWebAssemblyMemory.cpp:
918         (JSC::JSWebAssemblyMemory::buffer):
919         * wasm/js/WebAssemblyModuleConstructor.cpp:
920         (JSC::webAssemblyModuleCustomSections):
921
922 2019-03-07  Yusuke Suzuki  <ysuzuki@apple.com>
923
924         [JSC] Remove merging must handle values into proven types in CFA
925         https://bugs.webkit.org/show_bug.cgi?id=195444
926
927         Reviewed by Saam Barati.
928
929         Previously, we are merging must handle values as a proven constant in CFA. This is OK as long as this proven AbstractValue is blurred by merging the other legit AbstractValues
930         from the successors. But let's consider the following code, this is actually generated DFG graph from the attached test in r242626.
931
932             Block #2 (loop header) succ #3, #4
933             ...
934             1: ForceOSRExit
935             ...
936             2: JSConstant(0)
937             3: SetLocal(@2, loc6)
938             ...
939             4: Branch(#3, #4)
940
941             Block #3 (This is OSR entry target) pred #2, #3, must handle value for loc6 => JSConstant(Int32, 31)
942             ...
943             5: GetLocal(loc6)
944             6: StringFromCharCode(@5)
945             ...
946
947         Block #3 is OSR entry target. So we have must handle value for loc6 and it is Int32 constant 31. Then we merge this constant as a proven value in #3's loc6 AbstractValue.
948         If the value from #2 blurs the value, it is OK. However, #2 has ForceOSRExit. So must handle value suddenly becomes the only source of loc6 in #3. Then we use this constant
949         as a proven value. But this is not expected behavior since must handle value is just a snapshot of the locals when we kick off the concurrent compilation. In the above example,
950         we assume that loop index is an constant 31, but it is wrong, and OSR entry fails. Because there is no strong assumption that the must handle value is the proven type or value,
951         we should not merge it in CFA.
952
953         Since (1) this is just an optimization, (2) type information is already propagated in prediction injection phase, and (3) the must handle value does not show the performance
954         progression in r211461 and we no longer see type misprediction in marsaglia-osr-entry.js, this patch simply removes must handle value type widening in CFA.
955
956         * dfg/DFGCFAPhase.cpp:
957         (JSC::DFG::CFAPhase::run):
958         (JSC::DFG::CFAPhase::performBlockCFA):
959         (JSC::DFG::CFAPhase::injectOSR): Deleted.
960
961 2019-03-07  Yusuke Suzuki  <ysuzuki@apple.com>
962
963         [JSC] StringFromCharCode fast path should accept 0xff in DFG and FTL
964         https://bugs.webkit.org/show_bug.cgi?id=195429
965
966         Reviewed by Saam Barati.
967
968         We can create single characters without allocation up to 0xff character code. But currently, DFGSpeculativeJIT and FTLLowerDFGToB3 go to the slow path
969         for 0xff case. On the other hand, DFG DoesGC phase says GC won't happen if the child is int32 constant and it is <= 0xff. So, if you have `String.fromCharCode(0xff)`,
970         this breaks the assumption in DFG DoesGC. The correct fix is changing the check in DFGSpeculativeJIT and FTLLowerDFGToB3 from AboveOrEqual to Above.
971         Note that ThunkGenerators's StringFromCharCode thunk was correct.
972
973         * dfg/DFGSpeculativeJIT.cpp:
974         (JSC::DFG::SpeculativeJIT::compileFromCharCode):
975         * ftl/FTLLowerDFGToB3.cpp:
976         (JSC::FTL::DFG::LowerDFGToB3::compileStringFromCharCode):
977
978 2019-03-07  Mark Lam  <mark.lam@apple.com>
979
980         Follow up refactoring in try-finally code after r242591.
981         https://bugs.webkit.org/show_bug.cgi?id=195428
982
983         Reviewed by Saam Barati.
984
985         1. Added some comments in emitFinallyCompletion() to describe each completion case.
986         2. Converted CatchEntry into a struct.
987         3. Renamed variable hasBreaksOrContinuesNotCoveredByJumps to hasBreaksOrContinuesThatEscapeCurrentFinally
988            to be more clear about its purpose.
989
990         * bytecompiler/BytecodeGenerator.cpp:
991         (JSC::BytecodeGenerator::generate):
992         (JSC::BytecodeGenerator::emitOutOfLineExceptionHandler):
993         (JSC::BytecodeGenerator::emitFinallyCompletion):
994         * bytecompiler/BytecodeGenerator.h:
995
996 2019-03-07  Saam Barati  <sbarati@apple.com>
997
998         CompactVariableMap::Handle's copy operator= leaks the previous data
999         https://bugs.webkit.org/show_bug.cgi?id=195398
1000
1001         Reviewed by Yusuke Suzuki.
1002
1003         The copy constructor was just assigning |this| to the new value,
1004         forgetting to decrement the ref count of the thing pointed to by
1005         the |this| handle. Based on Yusuke's suggestion, this patch refactors
1006         the move constructor, move operator=, and copy operator= to use the
1007         swap() primitive and the copy constructor primitive.
1008
1009         * parser/VariableEnvironment.cpp:
1010         (JSC::CompactVariableMap::Handle::Handle):
1011         (JSC::CompactVariableMap::Handle::swap):
1012         (JSC::CompactVariableMap::Handle::operator=): Deleted.
1013         * parser/VariableEnvironment.h:
1014         (JSC::CompactVariableMap::Handle::Handle):
1015         (JSC::CompactVariableMap::Handle::operator=):
1016
1017 2019-03-07  Tadeu Zagallo  <tzagallo@apple.com>
1018
1019         Lazily decode cached bytecode
1020         https://bugs.webkit.org/show_bug.cgi?id=194810
1021
1022         Reviewed by Saam Barati.
1023
1024         Like lazy parsing, we should pause at code block boundaries. Instead
1025         of always eagerly decoding UnlinkedFunctionExecutable's UnlinkedCodeBlocks,
1026         we store their offsets in the executable and lazily decode them on the next
1027         call to `unlinkedCodeBlockFor`.
1028
1029         * bytecode/UnlinkedFunctionExecutable.cpp:
1030         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
1031         (JSC::UnlinkedFunctionExecutable::~UnlinkedFunctionExecutable):
1032         (JSC::UnlinkedFunctionExecutable::visitChildren):
1033         (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
1034         (JSC::UnlinkedFunctionExecutable::decodeCachedCodeBlocks):
1035         * bytecode/UnlinkedFunctionExecutable.h:
1036         * runtime/CachedTypes.cpp:
1037         (JSC::Decoder::Decoder):
1038         (JSC::Decoder::~Decoder):
1039         (JSC::Decoder::create):
1040         (JSC::Decoder::offsetOf):
1041         (JSC::Decoder::cacheOffset):
1042         (JSC::Decoder::ptrForOffsetFromBase):
1043         (JSC::Decoder::handleForEnvironment const):
1044         (JSC::Decoder::setHandleForEnvironment):
1045         (JSC::Decoder::addFinalizer):
1046         (JSC::VariableLengthObject::isEmpty const):
1047         (JSC::CachedWriteBarrier::isEmpty const):
1048         (JSC::CachedFunctionExecutable::unlinkedCodeBlockForCall const):
1049         (JSC::CachedFunctionExecutable::unlinkedCodeBlockForConstruct const):
1050         (JSC::CachedFunctionExecutable::decode const):
1051         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
1052         (JSC::decodeCodeBlockImpl):
1053         (JSC::isCachedBytecodeStillValid):
1054         (JSC::decodeFunctionCodeBlock):
1055         * runtime/CachedTypes.h:
1056         (JSC::Decoder::vm):
1057
1058 2019-03-06  Mark Lam  <mark.lam@apple.com>
1059
1060         Exception is a JSCell, not a JSObject.
1061         https://bugs.webkit.org/show_bug.cgi?id=195392
1062
1063         Reviewed by Saam Barati.
1064
1065         Exception is a VM implementation construct to carry a stack trace for the point
1066         where it is thrown from.  As a reminder, an Exception is needed because:
1067         1. JS code can throw primitives as well that are non-cells.
1068         2. Error objects capture the stack trace at the point where they are constructed,
1069            which is not always the same as the point where they are thrown (if they are
1070            thrown).
1071
1072         Hence, Exception should not be visible to JS code, and therefore should not be a
1073         JSObject.  Hence, it should not inherit from JSDestructibleObject.
1074
1075         This patch changes the following:
1076
1077         1. Exception now inherits directly from JSCell instead.
1078
1079         2. Places where we return an Exception masquerading as a JSObject* are now
1080            updated to return a nullptr when we encounter an exception.
1081
1082         3. We still return Exception* as JSValue or EncodedJSValue when we encounter an
1083            exception in functions that return JSValue or EncodedJSValue.  This is because
1084            the number that implements the following pattern is too numerous:
1085
1086                 return throw<Some Error>(...)
1087
1088            We'll leave these as is for now.
1089
1090         * bytecode/CodeBlock.h:
1091         (JSC::ScriptExecutable::prepareForExecution):
1092         * interpreter/Interpreter.cpp:
1093         (JSC::Interpreter::executeProgram):
1094         (JSC::Interpreter::executeCall):
1095         (JSC::Interpreter::executeConstruct):
1096         (JSC::Interpreter::prepareForRepeatCall):
1097         (JSC::Interpreter::execute):
1098         (JSC::Interpreter::executeModuleProgram):
1099         * jit/JITOperations.cpp:
1100         * llint/LLIntSlowPaths.cpp:
1101         (JSC::LLInt::setUpCall):
1102         * runtime/ConstructData.cpp:
1103         (JSC::construct):
1104         * runtime/Error.cpp:
1105         (JSC::throwConstructorCannotBeCalledAsFunctionTypeError):
1106         (JSC::throwTypeError):
1107         (JSC::throwSyntaxError):
1108         * runtime/Error.h:
1109         (JSC::throwRangeError):
1110         * runtime/Exception.cpp:
1111         (JSC::Exception::createStructure):
1112         * runtime/Exception.h:
1113         * runtime/ExceptionHelpers.cpp:
1114         (JSC::throwOutOfMemoryError):
1115         (JSC::throwStackOverflowError):
1116         (JSC::throwTerminatedExecutionException):
1117         * runtime/ExceptionHelpers.h:
1118         * runtime/FunctionConstructor.cpp:
1119         (JSC::constructFunction):
1120         (JSC::constructFunctionSkippingEvalEnabledCheck):
1121         * runtime/IntlPluralRules.cpp:
1122         (JSC::IntlPluralRules::resolvedOptions):
1123         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
1124         (JSC::constructGenericTypedArrayViewWithArguments):
1125         * runtime/JSObject.h:
1126         * runtime/ObjectConstructor.cpp:
1127         (JSC::objectConstructorSeal):
1128         (JSC::objectConstructorFreeze):
1129         * runtime/ProgramExecutable.cpp:
1130         (JSC::ProgramExecutable::initializeGlobalProperties):
1131         * runtime/RegExpConstructor.cpp:
1132         (JSC::regExpCreate):
1133         (JSC::constructRegExp):
1134         * runtime/ScriptExecutable.cpp:
1135         (JSC::ScriptExecutable::newCodeBlockFor):
1136         (JSC::ScriptExecutable::prepareForExecutionImpl):
1137         * runtime/ScriptExecutable.h:
1138         * runtime/ThrowScope.cpp:
1139         (JSC::ThrowScope::throwException):
1140         * runtime/ThrowScope.h:
1141         (JSC::ThrowScope::throwException):
1142         (JSC::throwException):
1143         * runtime/VM.cpp:
1144         (JSC::VM::throwException):
1145         * runtime/VM.h:
1146
1147 2019-03-06  Ross Kirsling  <ross.kirsling@sony.com>
1148
1149         [Win] Remove -DUCHAR_TYPE=wchar_t stopgap and learn to live with char16_t.
1150         https://bugs.webkit.org/show_bug.cgi?id=195346
1151
1152         Reviewed by Fujii Hironori.
1153
1154         * jsc.cpp:
1155         (currentWorkingDirectory):
1156         (fetchModuleFromLocalFileSystem):
1157         * runtime/DateConversion.cpp:
1158         (JSC::formatDateTime):
1159         Use wchar helpers as needed.
1160
1161 2019-03-06  Mark Lam  <mark.lam@apple.com>
1162
1163         Fix incorrect handling of try-finally completion values.
1164         https://bugs.webkit.org/show_bug.cgi?id=195131
1165         <rdar://problem/46222079>
1166
1167         Reviewed by Saam Barati and Yusuke Suzuki.
1168
1169         Consider the following:
1170
1171             function foo() {                        // line 1
1172                 try {
1173                     return 42;                      // line 3
1174                 } finally {
1175                     for (var j = 0; j < 1; j++) {   // line 5
1176                         try {
1177                             throw '';               // line 7
1178                         } finally {
1179                             continue;               // line 9
1180                         }
1181                     }
1182                 }                                   // line 11
1183             }
1184             var result = foo();
1185
1186         With the current (before fix) code base, result will be the exception object thrown
1187         at line 7.  The expected result should be 42, returned at line 3.
1188
1189         The bug is that we were previously only using one set of completion type and
1190         value registers for the entire function.  This is inadequate because the outer
1191         try-finally needs to preserve its own completion type and value ({ Return, 42 }
1192         in this case) in order to be able to complete correctly.
1193
1194         One might be deceived into thinking that the above example should complete with
1195         the exception thrown at line 7.  However, according to Section 13.15.8 of the
1196         ECMAScript spec, the 'continue' in the finally at line 9 counts as an abrupt
1197         completion.  As a result, it overrides the throw from line 7.  After the continue,
1198         execution resumes at the top of the loop at line 5, followed by a normal completion
1199         at line 11.
1200
1201         Also according to Section 13.15.8, given that the completion type of the outer
1202         finally is normal, the resultant completion of the outer try-finally should be
1203         the completion of the outer try block i.e. { Return, 42 }.
1204
1205         This patch makes the following changes:
1206         
1207         1. Fix handling of finally completion to use a unique set of completion
1208            type and value registers for each FinallyContext.
1209
1210         2. Move the setting of Throw completion type to the out of line exception handler.
1211            This makes the mainline code slightly less branchy.
1212
1213         3. Introduce emitOutOfLineCatchHandler(), emitOutOfLineFinallyHandler(), and
1214            emitOutOfLineExceptionHandler() to make it clearer that these are not emitting
1215            bytecode inline.  Also, these make it clearer when we're emitting a handler
1216            for a catch vs a finally.
1217
1218         4. Allocate the FinallyContext on the stack instead of as a member of the
1219            heap allocated ControlFlowScope.  This simplifies its life-cycle management
1220            and reduces the amount of needed copying.
1221
1222         5. Update emitFinallyCompletion() to propagate the completion type and value to
1223            the outer FinallyContext when needed.
1224
1225         6. Fix emitJumpIf() to use the right order of operands.  Previously, we were
1226            only using it to do op_stricteq and op_nstricteq comparisons.  So, the order
1227            wasn't important.  We now use it to also do op_beloweq comparisons.  Hence,
1228            the order needs to be corrected.
1229
1230         7. Remove the unused CompletionType::Break and Continue.  These are encoded with
1231            the jumpIDs of the jump targets instead.
1232
1233         Relevant specifications:
1234         Section 13.15.8: https://www.ecma-international.org/ecma-262/9.0/index.html#sec-try-statement-runtime-semantics-evaluation
1235         Section 6.3.2.4: https://www.ecma-international.org/ecma-262/9.0/index.html#sec-updateempty
1236
1237         * bytecompiler/BytecodeGenerator.cpp:
1238         (JSC::FinallyContext::FinallyContext):
1239         (JSC::BytecodeGenerator::generate):
1240         (JSC::BytecodeGenerator::BytecodeGenerator):
1241         (JSC::BytecodeGenerator::pushFinallyControlFlowScope):
1242         (JSC::BytecodeGenerator::popFinallyControlFlowScope):
1243         (JSC::BytecodeGenerator::emitOutOfLineCatchHandler):
1244         (JSC::BytecodeGenerator::emitOutOfLineFinallyHandler):
1245         (JSC::BytecodeGenerator::emitOutOfLineExceptionHandler):
1246         (JSC::BytecodeGenerator::emitEnumeration):
1247         (JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded):
1248         (JSC::BytecodeGenerator::emitReturnViaFinallyIfNeeded):
1249         (JSC::BytecodeGenerator::emitFinallyCompletion):
1250         (JSC::BytecodeGenerator::emitJumpIf):
1251         (JSC::BytecodeGenerator::emitCatch): Deleted.
1252         (JSC::BytecodeGenerator::allocateCompletionRecordRegisters): Deleted.
1253         (JSC::BytecodeGenerator::releaseCompletionRecordRegisters): Deleted.
1254         * bytecompiler/BytecodeGenerator.h:
1255         (JSC::FinallyContext::completionTypeRegister const):
1256         (JSC::FinallyContext::completionValueRegister const):
1257         (JSC::ControlFlowScope::ControlFlowScope):
1258         (JSC::BytecodeGenerator::emitLoad):
1259         (JSC::BytecodeGenerator::CompletionRecordScope::CompletionRecordScope): Deleted.
1260         (JSC::BytecodeGenerator::CompletionRecordScope::~CompletionRecordScope): Deleted.
1261         (JSC::BytecodeGenerator::completionTypeRegister const): Deleted.
1262         (JSC::BytecodeGenerator::completionValueRegister const): Deleted.
1263         (JSC::BytecodeGenerator::emitSetCompletionType): Deleted.
1264         (JSC::BytecodeGenerator::emitSetCompletionValue): Deleted.
1265         * bytecompiler/NodesCodegen.cpp:
1266         (JSC::TryNode::emitBytecode):
1267
1268 2019-03-06  Saam Barati  <sbarati@apple.com>
1269
1270         JSScript should keep the cache file locked for the duration of its existence and should truncate the cache when it is out of date
1271         https://bugs.webkit.org/show_bug.cgi?id=195186
1272
1273         Reviewed by Keith Miller.
1274
1275         This patch makes it so that JSScript will keep its bytecode cache file
1276         locked as long as the JSScript is alive. This makes it obvious that it's
1277         safe to update that file, as it will only be used in a single VM, across
1278         all processes, at a single time. We may be able to extend this in the future
1279         if we can atomically update it across VMs/processes. However, we're choosing
1280         more restricted semantics now as it's always easier to extend these semantics
1281         in the future opposed to having to support the more flexible behavior
1282         up front.
1283         
1284         This patch also:
1285         - Adds error messages if writing the cache fails. We don't expect this to
1286           fail, but previously we would say we cached it even if write() fails.
1287         - Removes the unused m_moduleKey field.
1288         - Makes calling cacheBytecodeWithError with an already non-empty cache file fail.
1289           In the future, we should extend this to just fill in the parts of the cache
1290           that are not present. But we don't have the ability to do that yet, so we
1291           just result in an error for now.
1292
1293         * API/JSScript.mm:
1294         (-[JSScript dealloc]):
1295         (-[JSScript readCache]):
1296         (-[JSScript init]):
1297         (-[JSScript writeCache:]):
1298         * API/JSScriptInternal.h:
1299         * API/tests/testapi.mm:
1300         (testCacheFileIsExclusive):
1301         (testCacheFileFailsWhenItsAlreadyCached):
1302         (testObjectiveCAPI):
1303
1304 2019-03-06  Christopher Reid  <chris.reid@sony.com>
1305
1306         Followups to (r242306): Use LockHolder instead of std::lock_guard on Remote Inspector Locks
1307         https://bugs.webkit.org/show_bug.cgi?id=195381
1308
1309         Reviewed by Mark Lam.
1310
1311         Replacing std::lock_guard uses in Remote Inspector with WTF::LockHolder.
1312         Also using `= { }` for struct initialization instead of memeset.
1313
1314         * inspector/remote/RemoteConnectionToTarget.cpp:
1315         * inspector/remote/RemoteInspector.cpp:
1316         * inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm:
1317         * inspector/remote/cocoa/RemoteInspectorCocoa.mm:
1318         * inspector/remote/cocoa/RemoteInspectorXPCConnection.mm:
1319         * inspector/remote/glib/RemoteInspectorGlib.cpp:
1320         * inspector/remote/playstation/RemoteInspectorPlayStation.cpp:
1321         * inspector/remote/playstation/RemoteInspectorSocketClientPlayStation.cpp:
1322         * inspector/remote/playstation/RemoteInspectorSocketPlayStation.cpp:
1323         * inspector/remote/playstation/RemoteInspectorSocketServerPlayStation.cpp:
1324
1325 2019-03-06  Saam Barati  <sbarati@apple.com>
1326
1327         Air::reportUsedRegisters must padInterference
1328         https://bugs.webkit.org/show_bug.cgi?id=195303
1329         <rdar://problem/48270343>
1330
1331         Reviewed by Keith Miller.
1332
1333         reportUsedRegisters uses reg liveness to eliminate loads/moves into dead
1334         registers. However, liveness can report incorrect results in certain 
1335         scenarios when considering liveness at instruction boundaries. For example,
1336         it can go wrong when an Inst has a LateUse of a register and the following
1337         Inst has an EarlyDef of that same register. Such a scenario could lead us
1338         to incorrectly say the register is not live-in to the first Inst. Pad
1339         interference inserts Nops between such instruction boundaries that cause
1340         this issue.
1341         
1342         The test with this patch fixes the issue in reportUsedRegisters. This patch
1343         also conservatively makes it so that lowerAfterRegAlloc calls padInterference
1344         since it also reasons about liveness.
1345
1346         * b3/air/AirLowerAfterRegAlloc.cpp:
1347         (JSC::B3::Air::lowerAfterRegAlloc):
1348         * b3/air/AirPadInterference.h:
1349         * b3/air/AirReportUsedRegisters.cpp:
1350         (JSC::B3::Air::reportUsedRegisters):
1351         * b3/testb3.cpp:
1352         (JSC::B3::testReportUsedRegistersLateUseNotDead):
1353         (JSC::B3::run):
1354
1355 2019-03-06  Yusuke Suzuki  <ysuzuki@apple.com>
1356
1357         [JSC] AI should not propagate AbstractValue relying on constant folding phase
1358         https://bugs.webkit.org/show_bug.cgi?id=195375
1359
1360         Reviewed by Saam Barati.
1361
1362         MakeRope rule in AI attempts to propagate the node, which will be produced after constant folding phase runs.
1363         This is wrong since we do not guarantee that constant folding phase runs after AI runs (e.g. DFGSpeculativeJIT
1364         and FTLLowerDFGToB3 run AI). This results in the bug that the value produced at runtime is different from the
1365         proven constant value in AI. In the attached test, AI says the value is SpecStringIdent while the resulted value
1366         at runtime is SpecStringVar, resulting in wrong MakeRope code. This patch removes the path propagating the node
1367         relying on constant folding phase.
1368
1369         * dfg/DFGAbstractInterpreterInlines.h:
1370         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1371
1372 2019-03-05  Saam barati  <sbarati@apple.com>
1373
1374         op_switch_char broken for rope strings after JSRopeString layout rewrite
1375         https://bugs.webkit.org/show_bug.cgi?id=195339
1376         <rdar://problem/48592545>
1377
1378         Reviewed by Yusuke Suzuki.
1379
1380         When we did the JSString rewrite, we accidentally broke LLInt's switch_char
1381         for rope strings. That change made it so that we always go to the slow path
1382         for ropes. That's wrong. The slow path should only be taken when the rope
1383         is of length 1. For lengths other than 1, we need to fall through to the
1384         default case. This patch fixes this.
1385
1386         * llint/LowLevelInterpreter32_64.asm:
1387         * llint/LowLevelInterpreter64.asm:
1388         * runtime/JSString.h:
1389
1390 2019-03-05  Yusuke Suzuki  <ysuzuki@apple.com>
1391
1392         [JSC] Should check exception for JSString::toExistingAtomicString
1393         https://bugs.webkit.org/show_bug.cgi?id=195337
1394
1395         Reviewed by Keith Miller, Saam Barati, and Mark Lam.
1396
1397         We missed the exception check for JSString::toExistingAtomicString while it can resolve
1398         a rope and throw an OOM exception. This patch adds necessary exception checks. This patch
1399         fixes test failures in debug build, reported in https://bugs.webkit.org/show_bug.cgi?id=194375#c93.
1400
1401         * dfg/DFGOperations.cpp:
1402         * jit/JITOperations.cpp:
1403         (JSC::getByVal):
1404         * llint/LLIntSlowPaths.cpp:
1405         (JSC::LLInt::getByVal):
1406         * runtime/CommonSlowPaths.cpp:
1407         (JSC::SLOW_PATH_DECL):
1408
1409 2019-03-04  Yusuke Suzuki  <ysuzuki@apple.com>
1410
1411         Unreviewed, build fix for debug builds after r242397
1412
1413         * runtime/JSString.h:
1414
1415 2019-03-04  Yusuke Suzuki  <ysuzuki@apple.com>
1416
1417         [JSC] Store bits for JSRopeString in 3 stores
1418         https://bugs.webkit.org/show_bug.cgi?id=195234
1419
1420         Reviewed by Saam Barati.
1421
1422         This patch cleans up the initialization of JSRopeString fields in DFG and FTL.
1423         Previously, we store some part of data separately. Instead, this patch calculates
1424         the data first by bit operations and store calculated data with fewer stores.
1425
1426         This patch also cleans up is8Bit and isSubstring flags. We put them in lower bits
1427         of the first fiber instead of the upper 16 bits. Since we only have 3 bit flags, (isRope, is8Bit, isSubstring),
1428         we can put them into the lower 3 bits, they are always empty due to alignment.
1429
1430         * bytecode/AccessCase.cpp:
1431         (JSC::AccessCase::generateImpl): A bit clean up of StringLength IC to give a chance of unnecessary mov removal.
1432         * dfg/DFGSpeculativeJIT.cpp:
1433         (JSC::DFG::SpeculativeJIT::canBeRope):
1434         (JSC::DFG::SpeculativeJIT::compileGetArrayLength):
1435         (JSC::DFG::SpeculativeJIT::compileMakeRope):
1436         * dfg/DFGSpeculativeJIT.h:
1437         * ftl/FTLAbstractHeapRepository.cpp:
1438         (JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
1439         * ftl/FTLAbstractHeapRepository.h:
1440         * ftl/FTLLowerDFGToB3.cpp:
1441         (JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
1442         (JSC::FTL::DFG::LowerDFGToB3::isRopeString):
1443         (JSC::FTL::DFG::LowerDFGToB3::isNotRopeString):
1444         * runtime/JSString.cpp:
1445         (JSC::JSString::visitChildren):
1446         * runtime/JSString.h:
1447         (JSC::JSString::is8Bit const):
1448         (JSC::JSString::isSubstring const):
1449         * tools/JSDollarVM.cpp:
1450         (JSC::functionCreateNullRopeString):
1451         (JSC::JSDollarVM::finishCreation):
1452
1453 2019-03-04  Joseph Pecoraro  <pecoraro@apple.com>
1454
1455         ITMLKit Inspector: Data Bindings / Associated Data for nodes
1456         https://bugs.webkit.org/show_bug.cgi?id=195290
1457         <rdar://problem/48304019>
1458
1459         Reviewed by Devin Rousso.
1460
1461         * inspector/protocol/DOM.json:
1462
1463 2019-03-04  Yusuke Suzuki  <ysuzuki@apple.com>
1464
1465         [JSC] Make Reflect lazily-allocated by dropping @Reflect references from builtin JS
1466         https://bugs.webkit.org/show_bug.cgi?id=195250
1467
1468         Reviewed by Saam Barati.
1469
1470         By removing @Reflect from builtin JS, we can make Reflect object allocation lazy.
1471         We move @ownKeys function from @Reflect to @Object to remove @Reflect reference.
1472
1473         We also remove m_intlObject field from JSGlobalObject since we no longer use it.
1474
1475         * builtins/BuiltinNames.h:
1476         * builtins/GlobalOperations.js:
1477         (globalPrivate.copyDataProperties):
1478         (globalPrivate.copyDataPropertiesNoExclusions):
1479         * runtime/JSGlobalObject.cpp:
1480         (JSC::createReflectProperty):
1481         (JSC::JSGlobalObject::init):
1482         (JSC::JSGlobalObject::visitChildren):
1483         * runtime/JSGlobalObject.h:
1484         * runtime/ObjectConstructor.cpp:
1485         (JSC::ObjectConstructor::finishCreation):
1486         (JSC::objectConstructorOwnKeys):
1487         * runtime/ReflectObject.cpp:
1488         (JSC::ReflectObject::finishCreation):
1489
1490 2019-03-04  Yusuke Suzuki  <ysuzuki@apple.com>
1491
1492         [JSC] Offer @makeTypeError instead of exposing @TypeError
1493         https://bugs.webkit.org/show_bug.cgi?id=193858
1494
1495         Reviewed by Mark Lam.
1496
1497         Instead of exposing @TypeError, we expose @makeTypeError function.
1498         And we make TypeError and Error lazily-allocated objects in non JIT environment.
1499         In JIT environment, only TypeError becomes lazily-allocated since WebAssembly errors
1500         touch Error prototype anyway. But we can make them lazy in a subsequent patch.
1501
1502         * builtins/AsyncFromSyncIteratorPrototype.js:
1503         * builtins/AsyncGeneratorPrototype.js:
1504         (globalPrivate.asyncGeneratorEnqueue):
1505         * builtins/BuiltinNames.h:
1506         * builtins/PromiseOperations.js:
1507         (globalPrivate.createResolvingFunctions.resolve):
1508         * runtime/JSGlobalObject.cpp:
1509         (JSC::JSGlobalObject::initializeErrorConstructor):
1510         (JSC::JSGlobalObject::init):
1511         (JSC::JSGlobalObject::visitChildren):
1512         * runtime/JSGlobalObject.h:
1513         (JSC::JSGlobalObject::errorPrototype const):
1514         (JSC::JSGlobalObject::errorStructure const):
1515         * runtime/JSGlobalObjectFunctions.cpp:
1516         (JSC::globalFuncMakeTypeError):
1517         * runtime/JSGlobalObjectFunctions.h:
1518
1519 2019-03-04  Carlos Garcia Campos  <cgarcia@igalia.com>
1520
1521         [GLib] Returning G_TYPE_OBJECT from a constructor does not work
1522         https://bugs.webkit.org/show_bug.cgi?id=195206
1523
1524         Reviewed by Žan Doberšek.
1525
1526         We are freeing the newly created object before returning from the constructor.
1527
1528         * API/glib/JSCCallbackFunction.cpp:
1529         (JSC::JSCCallbackFunction::construct):
1530
1531 2019-03-02  Darin Adler  <darin@apple.com>
1532
1533         Retire legacy dtoa function and DecimalNumber class
1534         https://bugs.webkit.org/show_bug.cgi?id=195253
1535
1536         Reviewed by Daniel Bates.
1537
1538         * runtime/NumberPrototype.cpp:
1539         (JSC::numberProtoFuncToExponential): Removed dependency on NumberToStringBufferLength,
1540         using NumberToStringBuffer instead. Also tweaked style of implementation a bit.
1541
1542 2019-03-01  Darin Adler  <darin@apple.com>
1543
1544         Finish removing String::format
1545         https://bugs.webkit.org/show_bug.cgi?id=194893
1546
1547         Reviewed by Daniel Bates.
1548
1549         * bytecode/CodeBlock.cpp:
1550         (JSC::CodeBlock::nameForRegister): Use makeString instead of String::format,
1551         using the new "pad" function.
1552
1553 2019-03-01  Christopher Reid  <chris.reid@sony.com>
1554
1555         [PlayStation] Upstream playstation's remote inspector server
1556         https://bugs.webkit.org/show_bug.cgi?id=193806
1557
1558         Reviewed by Joseph Pecoraro.
1559
1560         Upstreaming PlayStation's Remote Inspector implementation.
1561         It is using a JSON RPC protocol over TCP sockets.
1562         This inspector implementation is planned to also support running on a WinCairo Client and Server.
1563
1564         * PlatformPlayStation.cmake:
1565         * SourcesGTK.txt:
1566         * SourcesWPE.txt:
1567         * inspector/remote/RemoteConnectionToTarget.cpp: Renamed from Source/JavaScriptCore/inspector/remote/glib/RemoteConnectionToTargetGlib.cpp.
1568         * inspector/remote/RemoteInspector.h:
1569         * inspector/remote/playstation/RemoteInspectorConnectionClient.h: Added.
1570         * inspector/remote/playstation/RemoteInspectorConnectionClientPlayStation.cpp: Added.
1571         * inspector/remote/playstation/RemoteInspectorMessageParser.h: Added.
1572         * inspector/remote/playstation/RemoteInspectorMessageParserPlayStation.cpp: Added.
1573         * inspector/remote/playstation/RemoteInspectorPlayStation.cpp: Added.
1574         * inspector/remote/playstation/RemoteInspectorServer.h: Added.
1575         * inspector/remote/playstation/RemoteInspectorServerPlayStation.cpp: Added.
1576         * inspector/remote/playstation/RemoteInspectorSocket.h: Added.
1577         * inspector/remote/playstation/RemoteInspectorSocketClient.h: Added.
1578         * inspector/remote/playstation/RemoteInspectorSocketClientPlayStation.cpp: Added.
1579         * inspector/remote/playstation/RemoteInspectorSocketPlayStation.cpp: Added.
1580         * inspector/remote/playstation/RemoteInspectorSocketServer.h: Added.
1581         * inspector/remote/playstation/RemoteInspectorSocketServerPlayStation.cpp: Added.
1582
1583 2019-03-01  Saam Barati  <sbarati@apple.com>
1584
1585         Create SPI to crash if a JSC VM is created
1586         https://bugs.webkit.org/show_bug.cgi?id=195231
1587         <rdar://problem/47717990>
1588
1589         Reviewed by Mark Lam.
1590
1591         * API/JSVirtualMachine.mm:
1592         (+[JSVirtualMachine setCrashOnVMCreation:]):
1593         * API/JSVirtualMachinePrivate.h:
1594         * runtime/VM.cpp:
1595         (JSC::VM::VM):
1596         (JSC::VM::setCrashOnVMCreation):
1597         * runtime/VM.h:
1598
1599 2019-03-01  Yusuke Suzuki  <ysuzuki@apple.com>
1600
1601         [JSC] Fix FTL build on ARM32_64 by adding stubs for JSRopeString::offsetOfXXX
1602         https://bugs.webkit.org/show_bug.cgi?id=195235
1603
1604         Reviewed by Saam Barati.
1605
1606         This is a workaround until https://bugs.webkit.org/show_bug.cgi?id=195234 is done.
1607
1608         * runtime/JSString.h:
1609
1610 2019-03-01  Yusuke Suzuki  <ysuzuki@apple.com>
1611
1612         [JSC] Use runtime calls for DFG MakeRope if !CPU(ADDRESS64)
1613         https://bugs.webkit.org/show_bug.cgi?id=195221
1614
1615         Reviewed by Mark Lam.
1616
1617         ARM32_64 builds DFG 64bit, but the size of address is 32bit. Make DFG MakeRope a runtime call not only for DFG 32_64,
1618         but also DFG 64 with !CPU(ADDRESS64). This patch unifies compileMakeRope again, and use a runtime call for !CPU(ADDRESS64).
1619
1620         * dfg/DFGSpeculativeJIT.cpp:
1621         (JSC::DFG::SpeculativeJIT::compileMakeRope):
1622         * dfg/DFGSpeculativeJIT32_64.cpp:
1623         (JSC::DFG::SpeculativeJIT::compileMakeRope): Deleted.
1624         * dfg/DFGSpeculativeJIT64.cpp:
1625         (JSC::DFG::SpeculativeJIT::compileMakeRope): Deleted.
1626
1627 2019-03-01  Justin Fan  <justin_fan@apple.com>
1628
1629         [Web GPU] 32-bit builds broken by attempt to disable WebGPU on 32-bit
1630         https://bugs.webkit.org/show_bug.cgi?id=195191
1631
1632         Rubber-stamped by Dean Jackson.
1633
1634         Dropping support for 32-bit entirely, so I'm intentionally leaving 32-bit broken.
1635
1636         * Configurations/FeatureDefines.xcconfig:
1637
1638 2019-03-01  Dominik Infuehr  <dinfuehr@igalia.com>
1639
1640         Fix debug builds with GCC
1641         https://bugs.webkit.org/show_bug.cgi?id=195205
1642
1643         Unreviewed. Fix debug builds in GCC by removing
1644         the constexpr-keyword for this function.
1645
1646         * runtime/CachedTypes.cpp:
1647         (JSC::tagFromSourceCodeType):
1648
1649 2019-03-01  Dominik Infuehr  <dinfuehr@igalia.com>
1650
1651         [ARM] Fix assembler warnings in ctiMasmProbeTrampoline
1652         https://bugs.webkit.org/show_bug.cgi?id=195164
1653
1654         Reviewed by Mark Lam.
1655
1656         Short branches in IT blocks are deprecated in AArch32. In addition the
1657         the conditional branch was the only instruction in the IT block. Short
1658         branches are able to encode the condition code themselves, the additional
1659         IT instruction is not needed.
1660
1661         The assembler was also warning that writing into APSR without a bitmask
1662         was deprecated. Therefore use APSR_nzcvq instead, this generates the same
1663         instruction encoding.
1664
1665         * assembler/MacroAssemblerARMv7.cpp:
1666
1667 2019-02-28  Tadeu Zagallo  <tzagallo@apple.com>
1668
1669         Remove CachedPtr::m_isEmpty and CachedOptional::m_isEmpty fields
1670         https://bugs.webkit.org/show_bug.cgi?id=194999
1671
1672         Reviewed by Saam Barati.
1673
1674         These fields are unnecessary, since we can just check that m_offset
1675         has not been initialized (I added VariableLengthObject::isEmpty for
1676         that). They also add 7-byte padding to these classes, which is pretty
1677         bad given how frequently CachedPtr is used.
1678
1679         * runtime/CachedTypes.cpp:
1680         (JSC::CachedObject::operator new[]):
1681         (JSC::VariableLengthObject::allocate):
1682         (JSC::VariableLengthObject::isEmpty const):
1683         (JSC::CachedPtr::encode):
1684         (JSC::CachedPtr::decode const):
1685         (JSC::CachedPtr::get const):
1686         (JSC::CachedOptional::encode):
1687         (JSC::CachedOptional::decode const):
1688         (JSC::CachedOptional::decodeAsPtr const):
1689
1690 2019-02-28  Yusuke Suzuki  <ysuzuki@apple.com>
1691
1692         [JSC] sizeof(JSString) should be 16
1693         https://bugs.webkit.org/show_bug.cgi?id=194375
1694
1695         Reviewed by Saam Barati.
1696
1697         This patch reduces sizeof(JSString) from 24 to 16 to fit it into GC heap cell atom. And it also reduces sizeof(JSRopeString) from 48 to 32.
1698         Both classes cut 16 bytes per instance in GC allocation. This new layout is used in 64bit architectures which has little endianess.
1699
1700         JSString no longer has length and flags directly. JSString has String, and we query information to this String instead of holding duplicate
1701         information in JSString. We embed isRope bit into this String's pointer so that we can convert JSRopeString to JSString in an atomic manner.
1702         We emit store-store fence before we put String pointer. This should exist even before this patch, so this patch also fixes one concurrency issue.
1703
1704         The old JSRopeString separately had JSString* fibers along with String. In this patch, we merge the first JSString* fiber and String pointer
1705         storage into one to reduce the size of JSRopeString. JSRopeString has three pointer width storage. We pick 48bit effective address of JSString*
1706         fibers to compress three fibers + length + flags into three pointer width storage.
1707
1708         In 64bit architecture, JSString and JSRopeString have the following memory layout to make sizeof(JSString) == 16 and sizeof(JSRopeString) == 32.
1709         JSString has only one pointer. We use it for String. length() and is8Bit() queries go to StringImpl. In JSRopeString, we reuse the above pointer
1710         place for the 1st fiber. JSRopeString has three fibers so its size is 48. To keep length and is8Bit flag information in JSRopeString, JSRopeString
1711         encodes these information into the fiber pointers. is8Bit flag is encoded in the 1st fiber pointer. length is embedded directly, and two fibers
1712         are compressed into 12bytes. isRope information is encoded in the first fiber's LSB.
1713
1714         Since length of JSRopeString should be frequently accessed compared to each fiber, we put length in contiguous 32byte field, and compress 2nd
1715         and 3rd fibers into the following 80byte fields. One problem is that now 2nd and 3rd fibers are split. Storing and loading 2nd and 3rd fibers
1716         are not one pointer load operation. To make concurrent collector work correctly, we must initialize 2nd and 3rd fibers at JSRopeString creation
1717         and we must not modify these part later.
1718
1719                      0                        8        10               16                       32                                     48
1720         JSString     [   ID      ][  header  ][   String pointer      0]
1721         JSRopeString [   ID      ][  header  ][ flags ][ 1st fiber    1][  length  ][2nd lower32][2nd upper16][3rd lower16][3rd upper32]
1722                                                                       ^
1723                                                                    isRope bit
1724
1725         Since fibers in JSRopeString are not initialized in atomic pointer store manner, we must initialize all the fiber fields at JSRopeString creation.
1726         To achieve this, we modify our JSRopeString::RopeBuilder implementation not to create half-baked JSRopeString.
1727
1728         This patch also makes an empty JSString singleton per VM. This makes evaluation of JSString in boolean context one pointer comparison. This is
1729         critical in this change since this patch enlarges the code necessary to get length from JSString in JIT. Without this guarantee, our code of boolean
1730         context evaluation is bloated. This patch hides all the JSString::create and JSRopeString::create in the private permission. JSString and JSRopeString
1731         creation is only allowed from jsString and related helper functions and they return a singleton empty JSString if the length is zero. We also change
1732         JSRopeString::RopeBuilder not to construct an empty JSRopeString.
1733
1734         This patch is performance neutral in Speedometer2 and JetStream2. And it improves RAMification by 2.7%.
1735
1736         * JavaScriptCore.xcodeproj/project.pbxproj:
1737         * assembler/MacroAssemblerARM64.h:
1738         (JSC::MacroAssemblerARM64::storeZero16):
1739         * assembler/MacroAssemblerX86Common.h:
1740         (JSC::MacroAssemblerX86Common::storeZero16):
1741         (JSC::MacroAssemblerX86Common::store16):
1742         * bytecode/AccessCase.cpp:
1743         (JSC::AccessCase::generateImpl):
1744         * bytecode/InlineAccess.cpp:
1745         (JSC::InlineAccess::dumpCacheSizesAndCrash):
1746         (JSC::linkCodeInline):
1747         (JSC::InlineAccess::isCacheableStringLength):
1748         (JSC::InlineAccess::generateStringLength):
1749         * bytecode/InlineAccess.h:
1750         (JSC::InlineAccess::sizeForPropertyAccess):
1751         (JSC::InlineAccess::sizeForPropertyReplace):
1752         (JSC::InlineAccess::sizeForLengthAccess):
1753         * dfg/DFGOperations.cpp:
1754         * dfg/DFGOperations.h:
1755         * dfg/DFGSpeculativeJIT.cpp:
1756         (JSC::DFG::SpeculativeJIT::compileStringSlice):
1757         (JSC::DFG::SpeculativeJIT::compileToLowerCase):
1758         (JSC::DFG::SpeculativeJIT::compileGetCharCodeAt):
1759         (JSC::DFG::SpeculativeJIT::compileGetByValOnString):
1760         (JSC::DFG::SpeculativeJIT::compileStringEquality):
1761         (JSC::DFG::SpeculativeJIT::compileStringZeroLength):
1762         (JSC::DFG::SpeculativeJIT::compileLogicalNotStringOrOther):
1763         (JSC::DFG::SpeculativeJIT::emitStringBranch):
1764         (JSC::DFG::SpeculativeJIT::emitStringOrOtherBranch):
1765         (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
1766         (JSC::DFG::SpeculativeJIT::compileGetArrayLength):
1767         (JSC::DFG::SpeculativeJIT::emitPopulateSliceIndex):
1768         (JSC::DFG::SpeculativeJIT::compileArraySlice):
1769         (JSC::DFG::SpeculativeJIT::compileArrayIndexOf):
1770         (JSC::DFG::SpeculativeJIT::speculateStringIdentAndLoadStorage):
1771         (JSC::DFG::SpeculativeJIT::emitSwitchCharStringJump):
1772         (JSC::DFG::SpeculativeJIT::emitSwitchStringOnString):
1773         (JSC::DFG::SpeculativeJIT::compileMakeRope): Deleted.
1774         * dfg/DFGSpeculativeJIT.h:
1775         * dfg/DFGSpeculativeJIT32_64.cpp:
1776         (JSC::DFG::SpeculativeJIT::compile):
1777         (JSC::DFG::SpeculativeJIT::compileMakeRope):
1778         * dfg/DFGSpeculativeJIT64.cpp:
1779         (JSC::DFG::SpeculativeJIT::compile):
1780         (JSC::DFG::SpeculativeJIT::compileMakeRope):
1781         * ftl/FTLAbstractHeapRepository.cpp:
1782         (JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
1783         * ftl/FTLAbstractHeapRepository.h:
1784         * ftl/FTLLowerDFGToB3.cpp:
1785         (JSC::FTL::DFG::LowerDFGToB3::compileGetIndexedPropertyStorage):
1786         (JSC::FTL::DFG::LowerDFGToB3::compileGetArrayLength):
1787         (JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
1788         (JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
1789         (JSC::FTL::DFG::LowerDFGToB3::compileStringCharCodeAt):
1790         (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
1791         (JSC::FTL::DFG::LowerDFGToB3::compileStringToUntypedStrictEquality):
1792         (JSC::FTL::DFG::LowerDFGToB3::compileSwitch):
1793         (JSC::FTL::DFG::LowerDFGToB3::mapHashString):
1794         (JSC::FTL::DFG::LowerDFGToB3::compileMapHash):
1795         (JSC::FTL::DFG::LowerDFGToB3::compileHasOwnProperty):
1796         (JSC::FTL::DFG::LowerDFGToB3::compileStringSlice):
1797         (JSC::FTL::DFG::LowerDFGToB3::compileToLowerCase):
1798         (JSC::FTL::DFG::LowerDFGToB3::stringsEqual):
1799         (JSC::FTL::DFG::LowerDFGToB3::boolify):
1800         (JSC::FTL::DFG::LowerDFGToB3::switchString):
1801         (JSC::FTL::DFG::LowerDFGToB3::isRopeString):
1802         (JSC::FTL::DFG::LowerDFGToB3::isNotRopeString):
1803         (JSC::FTL::DFG::LowerDFGToB3::speculateStringIdent):
1804         * jit/AssemblyHelpers.cpp:
1805         (JSC::AssemblyHelpers::emitConvertValueToBoolean):
1806         (JSC::AssemblyHelpers::branchIfValue):
1807         * jit/AssemblyHelpers.h:
1808         (JSC::AssemblyHelpers::branchIfRopeStringImpl):
1809         (JSC::AssemblyHelpers::branchIfNotRopeStringImpl):
1810         * jit/JITInlines.h:
1811         (JSC::JIT::emitLoadCharacterString):
1812         * jit/Repatch.cpp:
1813         (JSC::tryCacheGetByID):
1814         * jit/ThunkGenerators.cpp:
1815         (JSC::stringGetByValGenerator):
1816         (JSC::stringCharLoad):
1817         * llint/LowLevelInterpreter.asm:
1818         * llint/LowLevelInterpreter32_64.asm:
1819         * llint/LowLevelInterpreter64.asm:
1820         * runtime/JSString.cpp:
1821         (JSC::JSString::createEmptyString):
1822         (JSC::JSRopeString::RopeBuilder<RecordOverflow>::expand):
1823         (JSC::JSString::dumpToStream):
1824         (JSC::JSString::estimatedSize):
1825         (JSC::JSString::visitChildren):
1826         (JSC::JSRopeString::resolveRopeInternal8 const):
1827         (JSC::JSRopeString::resolveRopeInternal8NoSubstring const):
1828         (JSC::JSRopeString::resolveRopeInternal16 const):
1829         (JSC::JSRopeString::resolveRopeInternal16NoSubstring const):
1830         (JSC::JSRopeString::resolveRopeToAtomicString const):
1831         (JSC::JSRopeString::convertToNonRope const):
1832         (JSC::JSRopeString::resolveRopeToExistingAtomicString const):
1833         (JSC::JSRopeString::resolveRopeWithFunction const):
1834         (JSC::JSRopeString::resolveRope const):
1835         (JSC::JSRopeString::resolveRopeSlowCase8 const):
1836         (JSC::JSRopeString::resolveRopeSlowCase const):
1837         (JSC::JSRopeString::outOfMemory const):
1838         (JSC::JSRopeString::visitFibers): Deleted.
1839         (JSC::JSRopeString::clearFibers const): Deleted.
1840         * runtime/JSString.h:
1841         (JSC::JSString::uninitializedValueInternal const):
1842         (JSC::JSString::valueInternal const):
1843         (JSC::JSString::JSString):
1844         (JSC::JSString::finishCreation):
1845         (JSC::JSString::create):
1846         (JSC::JSString::offsetOfValue):
1847         (JSC::JSString::isRope const):
1848         (JSC::JSString::is8Bit const):
1849         (JSC::JSString::length const):
1850         (JSC::JSString::tryGetValueImpl const):
1851         (JSC::JSString::toAtomicString const):
1852         (JSC::JSString::toExistingAtomicString const):
1853         (JSC::JSString::value const):
1854         (JSC::JSString::tryGetValue const):
1855         (JSC::JSRopeString::unsafeView const):
1856         (JSC::JSRopeString::viewWithUnderlyingString const):
1857         (JSC::JSString::unsafeView const):
1858         (JSC::JSString::viewWithUnderlyingString const):
1859         (JSC::JSString::offsetOfLength): Deleted.
1860         (JSC::JSString::offsetOfFlags): Deleted.
1861         (JSC::JSString::setIs8Bit const): Deleted.
1862         (JSC::JSString::setLength): Deleted.
1863         (JSC::JSString::string): Deleted.
1864         (JSC::jsStringBuilder): Deleted.
1865         * runtime/JSStringInlines.h:
1866         (JSC::JSString::~JSString):
1867         (JSC::JSString::equal const):
1868         * runtime/ObjectPrototype.cpp:
1869         (JSC::objectProtoFuncToString):
1870         * runtime/RegExpMatchesArray.h:
1871         (JSC::createRegExpMatchesArray):
1872         * runtime/RegExpObjectInlines.h:
1873         (JSC::collectMatches):
1874         * runtime/RegExpPrototype.cpp:
1875         (JSC::regExpProtoFuncSplitFast):
1876         * runtime/SmallStrings.cpp:
1877         (JSC::SmallStrings::initializeCommonStrings):
1878         (JSC::SmallStrings::createEmptyString): Deleted.
1879         * runtime/SmallStrings.h:
1880         * runtime/StringPrototype.cpp:
1881         (JSC::stringProtoFuncSlice):
1882         * runtime/StringPrototypeInlines.h: Added.
1883         (JSC::stringSlice):
1884
1885 2019-02-28  Saam barati  <sbarati@apple.com>
1886
1887         Unreviewed. Attempt windows build fix after r242239.
1888
1889         * runtime/CachedTypes.cpp:
1890         (JSC::tagFromSourceCodeType):
1891
1892 2019-02-28  Mark Lam  <mark.lam@apple.com>
1893
1894         In cloop.rb, rename :int and :uint to :intptr and :uintptr.
1895         https://bugs.webkit.org/show_bug.cgi?id=195183
1896
1897         Reviewed by Yusuke Suzuki.
1898
1899         Also changed intMemRef and uintMemRef to intptrMemRef and uintptrMemRef respectively.
1900
1901         * offlineasm/cloop.rb:
1902
1903 2019-02-28  Saam barati  <sbarati@apple.com>
1904
1905         Make JSScript:cacheBytecodeWithError update the cache when the script changes
1906         https://bugs.webkit.org/show_bug.cgi?id=194912
1907
1908         Reviewed by Mark Lam.
1909
1910         Prior to this patch, the JSScript SPI would never check if its cached
1911         bytecode were still valid. This would lead the cacheBytecodeWithError
1912         succeeding even if the underlying cache were stale. This patch fixes
1913         that by making JSScript check if the cache is still valid. If it's not,
1914         we will cache bytecode when cacheBytecodeWithError is invoked.
1915
1916         * API/JSScript.mm:
1917         (-[JSScript readCache]):
1918         (-[JSScript writeCache:]):
1919         * API/tests/testapi.mm:
1920         (testBytecodeCacheWithSameCacheFileAndDifferentScript):
1921         (testObjectiveCAPI):
1922         * runtime/CachedTypes.cpp:
1923         (JSC::Decoder::Decoder):
1924         (JSC::VariableLengthObject::buffer const):
1925         (JSC::CachedPtr::decode const):
1926         (JSC::tagFromSourceCodeType):
1927         (JSC::GenericCacheEntry::isUpToDate const):
1928         (JSC::CacheEntry::isStillValid const):
1929         (JSC::GenericCacheEntry::decode const):
1930         (JSC::GenericCacheEntry::isStillValid const):
1931         (JSC::encodeCodeBlock):
1932         (JSC::decodeCodeBlockImpl):
1933         (JSC::isCachedBytecodeStillValid):
1934         * runtime/CachedTypes.h:
1935         * runtime/CodeCache.cpp:
1936         (JSC::sourceCodeKeyForSerializedBytecode):
1937         (JSC::sourceCodeKeyForSerializedProgram):
1938         (JSC::sourceCodeKeyForSerializedModule):
1939         (JSC::serializeBytecode):
1940         * runtime/CodeCache.h:
1941         (JSC::CodeCacheMap::fetchFromDiskImpl):
1942         * runtime/Completion.cpp:
1943         (JSC::generateProgramBytecode):
1944         (JSC::generateBytecode): Deleted.
1945         * runtime/Completion.h:
1946
1947 2019-02-28  Mark Lam  <mark.lam@apple.com>
1948
1949         cloop.rb shift mask should depend on the word size being shifted.
1950         https://bugs.webkit.org/show_bug.cgi?id=195181
1951         <rdar://problem/48484164>
1952
1953         Reviewed by Yusuke Suzuki.
1954
1955         Previously, we're always masking the shift amount with 0x1f.  This is only correct
1956         for 32-bit words.  For 64-bit words, the mask should be 0x3f.  For pointer sized
1957         shifts, the mask depends on sizeof(uintptr_t).
1958
1959         * offlineasm/cloop.rb:
1960
1961 2019-02-28  Justin Fan  <justin_fan@apple.com>
1962
1963         [Web GPU] Enable Web GPU only on 64-bit
1964         https://bugs.webkit.org/show_bug.cgi?id=195139
1965
1966         Because Metal is only supported on 64 bit apps.
1967
1968         Unreviewed build fix.
1969
1970         * Configurations/FeatureDefines.xcconfig:
1971
1972 2019-02-27  Mark Lam  <mark.lam@apple.com>
1973
1974         The parser is failing to record the token location of new in new.target.
1975         https://bugs.webkit.org/show_bug.cgi?id=195127
1976         <rdar://problem/39645578>
1977
1978         Reviewed by Yusuke Suzuki.
1979
1980         Also adjust the token location for the following to be as shown:
1981
1982             new.target
1983             ^
1984             super
1985             ^
1986             import.meta
1987             ^
1988
1989         * parser/Parser.cpp:
1990         (JSC::Parser<LexerType>::parseMemberExpression):
1991
1992 2019-02-27  Yusuke Suzuki  <ysuzuki@apple.com>
1993
1994         [JSC] mustHandleValues for dead bytecode locals should be ignored in DFG phases
1995         https://bugs.webkit.org/show_bug.cgi?id=195144
1996         <rdar://problem/47595961>
1997
1998         Reviewed by Mark Lam.
1999
2000         DFGMaximalFlushInsertionPhase inserts Flush for all the locals at the end of basic blocks. This enlarges the live ranges of
2001         locals in DFG, and it sometimes makes DFG value live while it is dead in bytecode. The issue happens when we use mustHandleValues
2002         to widen AbstractValue in CFAPhase. At that time, DFG tells "this value is live in DFG", but it may be dead in the bytecode level.
2003         At that time, we attempt to merge AbstractValue with dead mustHandleValue, which is cleared as jsUndefined() in
2004         DFG::Plan::cleanMustHandleValuesIfNecessary before start compilation, and crash because jsUndefined() may be irrelevant to the FlushFormat
2005         in VariableAccessData.
2006
2007         This patch makes the type of mustHandleValues Operands<Optional<JSValue>>. We clear dead JSValues in DFG::Plan::cleanMustHandleValuesIfNecessary.
2008         And we skip handling dead mustHandleValue in DFG phases.
2009
2010         * bytecode/Operands.h:
2011         (JSC::Operands::isLocal const):
2012         (JSC::Operands::isVariable const): Deleted.
2013         * dfg/DFGCFAPhase.cpp:
2014         (JSC::DFG::CFAPhase::injectOSR):
2015         * dfg/DFGDriver.cpp:
2016         (JSC::DFG::compileImpl):
2017         (JSC::DFG::compile):
2018         * dfg/DFGDriver.h:
2019         * dfg/DFGJITCode.cpp:
2020         (JSC::DFG::JITCode::reconstruct):
2021         * dfg/DFGJITCode.h:
2022         * dfg/DFGOperations.cpp:
2023         * dfg/DFGPlan.cpp:
2024         (JSC::DFG::Plan::Plan):
2025         (JSC::DFG::Plan::checkLivenessAndVisitChildren):
2026         (JSC::DFG::Plan::cleanMustHandleValuesIfNecessary):
2027         * dfg/DFGPlan.h:
2028         (JSC::DFG::Plan::mustHandleValues const):
2029         * dfg/DFGPredictionInjectionPhase.cpp:
2030         (JSC::DFG::PredictionInjectionPhase::run):
2031         * dfg/DFGTypeCheckHoistingPhase.cpp:
2032         (JSC::DFG::TypeCheckHoistingPhase::disableHoistingAcrossOSREntries):
2033         * ftl/FTLOSREntry.cpp:
2034         (JSC::FTL::prepareOSREntry):
2035         * jit/JITOperations.cpp:
2036
2037 2019-02-27  Simon Fraser  <simon.fraser@apple.com>
2038
2039         Roll out r242014; it caused crashes in compositing logging (webkit.org/b/195141)
2040
2041         * bytecode/CodeBlock.cpp:
2042         (JSC::CodeBlock::nameForRegister):
2043
2044 2019-02-27  Robin Morisset  <rmorisset@apple.com>
2045
2046         DFG: Loop-invariant code motion (LICM) should not hoist dead code
2047         https://bugs.webkit.org/show_bug.cgi?id=194945
2048         <rdar://problem/48311657>
2049
2050         Reviewed by Saam Barati.
2051
2052         * dfg/DFGLICMPhase.cpp:
2053         (JSC::DFG::LICMPhase::run):
2054
2055 2019-02-27  Antoine Quint  <graouts@apple.com>
2056
2057         Support Pointer Events on macOS
2058         https://bugs.webkit.org/show_bug.cgi?id=195008
2059         <rdar://problem/47454419>
2060
2061         Reviewed by Dean Jackson.
2062
2063         * Configurations/FeatureDefines.xcconfig:
2064
2065 2019-02-26  Mark Lam  <mark.lam@apple.com>
2066
2067         Remove poisons in JSCPoison and uses of them.
2068         https://bugs.webkit.org/show_bug.cgi?id=195082
2069
2070         Reviewed by Yusuke Suzuki.
2071
2072         Also removed unused poisoning code in WriteBarrier, AssemblyHelpers,
2073         DFG::SpeculativeJIT, FTLLowerDFGToB3, and FTL::Output.
2074
2075         * API/JSAPIWrapperObject.h:
2076         (JSC::JSAPIWrapperObject::wrappedObject):
2077         * API/JSCallbackFunction.h:
2078         * API/JSCallbackObject.h:
2079         * API/glib/JSAPIWrapperGlobalObject.h:
2080         * CMakeLists.txt:
2081         * JavaScriptCore.xcodeproj/project.pbxproj:
2082         * Sources.txt:
2083         * bytecode/AccessCase.cpp:
2084         (JSC::AccessCase::generateWithGuard):
2085         * dfg/DFGSpeculativeJIT.cpp:
2086         (JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments):
2087         (JSC::DFG::SpeculativeJIT::compileGetArrayLength):
2088         (JSC::DFG::SpeculativeJIT::compileNewFunctionCommon):
2089         (JSC::DFG::SpeculativeJIT::compileGetExecutable):
2090         (JSC::DFG::SpeculativeJIT::compileCreateThis):
2091         * dfg/DFGSpeculativeJIT.h:
2092         (JSC::DFG::SpeculativeJIT::TrustedImmPtr::weakPoisonedPointer): Deleted.
2093         * ftl/FTLLowerDFGToB3.cpp:
2094         (JSC::FTL::DFG::LowerDFGToB3::compileGetExecutable):
2095         (JSC::FTL::DFG::LowerDFGToB3::compileGetArrayLength):
2096         (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
2097         (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
2098         (JSC::FTL::DFG::LowerDFGToB3::weakPointer):
2099         (JSC::FTL::DFG::LowerDFGToB3::dynamicPoison): Deleted.
2100         (JSC::FTL::DFG::LowerDFGToB3::dynamicPoisonOnLoadedType): Deleted.
2101         (JSC::FTL::DFG::LowerDFGToB3::dynamicPoisonOnType): Deleted.
2102         (JSC::FTL::DFG::LowerDFGToB3::weakPoisonedPointer): Deleted.
2103         * ftl/FTLOutput.h:
2104         (JSC::FTL::Output::weakPoisonedPointer): Deleted.
2105         * jit/AssemblyHelpers.cpp:
2106         (JSC::AssemblyHelpers::emitDynamicPoison): Deleted.
2107         (JSC::AssemblyHelpers::emitDynamicPoisonOnLoadedType): Deleted.
2108         (JSC::AssemblyHelpers::emitDynamicPoisonOnType): Deleted.
2109         * jit/AssemblyHelpers.h:
2110         * jit/JITOpcodes.cpp:
2111         (JSC::JIT::emit_op_create_this):
2112         * jit/JITPropertyAccess.cpp:
2113         (JSC::JIT::emitScopedArgumentsGetByVal):
2114         * jit/Repatch.cpp:
2115         (JSC::linkPolymorphicCall):
2116         * jit/ThunkGenerators.cpp:
2117         (JSC::virtualThunkFor):
2118         (JSC::nativeForGenerator):
2119         (JSC::boundThisNoArgsFunctionCallGenerator):
2120         * parser/UnlinkedSourceCode.h:
2121         * runtime/ArrayPrototype.h:
2122         * runtime/CustomGetterSetter.h:
2123         (JSC::CustomGetterSetter::getter const):
2124         (JSC::CustomGetterSetter::setter const):
2125         * runtime/InitializeThreading.cpp:
2126         (JSC::initializeThreading):
2127         * runtime/InternalFunction.cpp:
2128         (JSC::InternalFunction::getCallData):
2129         (JSC::InternalFunction::getConstructData):
2130         * runtime/InternalFunction.h:
2131         (JSC::InternalFunction::nativeFunctionFor):
2132         * runtime/JSArrayBuffer.h:
2133         * runtime/JSBoundFunction.h:
2134         * runtime/JSCPoison.cpp: Removed.
2135         * runtime/JSCPoison.h: Removed.
2136         * runtime/JSFunction.h:
2137         * runtime/JSGlobalObject.h:
2138         * runtime/JSScriptFetchParameters.h:
2139         * runtime/JSScriptFetcher.h:
2140         * runtime/JSString.h:
2141         * runtime/NativeExecutable.cpp:
2142         (JSC::NativeExecutable::hashFor const):
2143         * runtime/NativeExecutable.h:
2144         * runtime/Options.h:
2145         * runtime/ScopedArguments.h:
2146         * runtime/Structure.cpp:
2147         (JSC::StructureTransitionTable::setSingleTransition):
2148         * runtime/StructureTransitionTable.h:
2149         (JSC::StructureTransitionTable::map const):
2150         (JSC::StructureTransitionTable::weakImpl const):
2151         (JSC::StructureTransitionTable::setMap):
2152         * runtime/WriteBarrier.h:
2153         * wasm/WasmB3IRGenerator.cpp:
2154         * wasm/WasmInstance.h:
2155         * wasm/js/JSToWasm.cpp:
2156         (JSC::Wasm::createJSToWasmWrapper):
2157         * wasm/js/JSWebAssemblyCodeBlock.h:
2158         * wasm/js/JSWebAssemblyInstance.cpp:
2159         (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
2160         (JSC::JSWebAssemblyInstance::visitChildren):
2161         * wasm/js/JSWebAssemblyInstance.h:
2162         * wasm/js/JSWebAssemblyMemory.h:
2163         * wasm/js/JSWebAssemblyModule.h:
2164         * wasm/js/JSWebAssemblyTable.cpp:
2165         (JSC::JSWebAssemblyTable::JSWebAssemblyTable):
2166         (JSC::JSWebAssemblyTable::grow):
2167         (JSC::JSWebAssemblyTable::clearFunction):
2168         * wasm/js/JSWebAssemblyTable.h:
2169         * wasm/js/WasmToJS.cpp:
2170         (JSC::Wasm::materializeImportJSCell):
2171         (JSC::Wasm::handleBadI64Use):
2172         (JSC::Wasm::wasmToJS):
2173         * wasm/js/WebAssemblyFunctionBase.h:
2174         * wasm/js/WebAssemblyModuleRecord.cpp:
2175         (JSC::WebAssemblyModuleRecord::link):
2176         (JSC::WebAssemblyModuleRecord::evaluate):
2177         * wasm/js/WebAssemblyModuleRecord.h:
2178         * wasm/js/WebAssemblyToJSCallee.h:
2179         * wasm/js/WebAssemblyWrapperFunction.h:
2180
2181 2019-02-26  Mark Lam  <mark.lam@apple.com>
2182
2183         wasmToJS() should purify incoming NaNs.
2184         https://bugs.webkit.org/show_bug.cgi?id=194807
2185         <rdar://problem/48189132>
2186
2187         Reviewed by Saam Barati.
2188
2189         * runtime/JSCJSValue.h:
2190         (JSC::jsNumber):
2191         * runtime/TypedArrayAdaptors.h:
2192         (JSC::IntegralTypedArrayAdaptor::toJSValue):
2193         * wasm/js/WasmToJS.cpp:
2194         (JSC::Wasm::wasmToJS):
2195
2196 2019-02-26  Dominik Infuehr  <dinfuehr@igalia.com>
2197
2198         Fix warnings on ARM and MIPS
2199         https://bugs.webkit.org/show_bug.cgi?id=195049
2200
2201         Reviewed by Mark Lam.
2202
2203         Fix all warnings on ARM and MIPS.
2204
2205         * assembler/MacroAssemblerPrinter.cpp:
2206         (JSC::Printer::printMemory):
2207         * assembler/testmasm.cpp:
2208         (JSC::testProbeModifiesStackValues):
2209         * bytecode/InByIdStatus.cpp:
2210         (JSC::InByIdStatus::computeFor):
2211         * runtime/CachedTypes.cpp:
2212         (JSC::VariableLengthObject::buffer const):
2213         * runtime/JSBigInt.h:
2214         * tools/JSDollarVM.cpp:
2215         (JSC::codeBlockFromArg):
2216
2217 2019-02-26  Mark Lam  <mark.lam@apple.com>
2218
2219         Misc cleanup in StructureIDTable after r242096.
2220         https://bugs.webkit.org/show_bug.cgi?id=195063
2221
2222         Reviewed by Saam Barati.
2223
2224         * runtime/StructureIDTable.cpp:
2225         (JSC::StructureIDTable::allocateID):
2226         - RELEASE_ASSERT that the StructureID allocation will succeed.
2227
2228         * runtime/StructureIDTable.h:
2229         (JSC::StructureIDTable::decode):
2230         (JSC::StructureIDTable::encode):
2231         - Add back a comment that Yusuke requested but was lost when the patch was rolled
2232           out and relanded.
2233         - Applied bitwise_casts that Saam requested.
2234
2235 2019-02-26  Mark Lam  <mark.lam@apple.com>
2236
2237         Gardening: 32-bit build fix after r242096.
2238         https://bugs.webkit.org/show_bug.cgi?id=194989
2239
2240         Not reviewed.
2241
2242         * jit/AssemblyHelpers.cpp:
2243         (JSC::AssemblyHelpers::emitLoadStructure):
2244
2245 2019-02-26  Mark Lam  <mark.lam@apple.com>
2246
2247         Unpoison MacroAssemblerCodePtr, ClassInfo pointers, and a few other things.
2248         https://bugs.webkit.org/show_bug.cgi?id=195039
2249
2250         Reviewed by Saam Barati.
2251
2252         1. Unpoison MacroAssemblerCodePtrs, ReturnAddressPtr.
2253         2. Replace PoisonedClassInfoPtr with ClassInfo*.
2254         3. Replace PoisonedMasmPtr with const void*.
2255         4. Remove all references to CodeBlockPoison, JITCodePoison, and GlobalDataPoison.
2256
2257         * API/JSCallbackObject.h:
2258         * API/JSObjectRef.cpp:
2259         (classInfoPrivate):
2260         * assembler/MacroAssemblerCodeRef.h:
2261         (JSC::FunctionPtr::FunctionPtr):
2262         (JSC::FunctionPtr::executableAddress const):
2263         (JSC::FunctionPtr::retaggedExecutableAddress const):
2264         (JSC::ReturnAddressPtr::ReturnAddressPtr):
2265         (JSC::ReturnAddressPtr::value const):
2266         (JSC::MacroAssemblerCodePtr::MacroAssemblerCodePtr):
2267         (JSC::MacroAssemblerCodePtr::createFromExecutableAddress):
2268         (JSC::MacroAssemblerCodePtr:: const):
2269         (JSC::MacroAssemblerCodePtr::operator! const):
2270         (JSC::MacroAssemblerCodePtr::operator== const):
2271         (JSC::MacroAssemblerCodePtr::hash const):
2272         (JSC::MacroAssemblerCodePtr::emptyValue):
2273         (JSC::MacroAssemblerCodePtr::deletedValue):
2274         (JSC::FunctionPtr<tag>::FunctionPtr):
2275         (JSC::MacroAssemblerCodePtr::poisonedPtr const): Deleted.
2276         * b3/B3LowerMacros.cpp:
2277         * b3/testb3.cpp:
2278         (JSC::B3::testInterpreter):
2279         * dfg/DFGOSRExitCompilerCommon.h:
2280         (JSC::DFG::adjustFrameAndStackInOSRExitCompilerThunk):
2281         * dfg/DFGSpeculativeJIT.cpp:
2282         (JSC::DFG::SpeculativeJIT::compileCheckSubClass):
2283         (JSC::DFG::SpeculativeJIT::compileNewStringObject):
2284         (JSC::DFG::SpeculativeJIT::emitSwitchIntJump):
2285         (JSC::DFG::SpeculativeJIT::emitSwitchImm):
2286         (JSC::DFG::SpeculativeJIT::emitSwitchCharStringJump):
2287         (JSC::DFG::SpeculativeJIT::emitSwitchChar):
2288         * dfg/DFGSpeculativeJIT.h:
2289         * ftl/FTLLowerDFGToB3.cpp:
2290         (JSC::FTL::DFG::LowerDFGToB3::compileNewStringObject):
2291         (JSC::FTL::DFG::LowerDFGToB3::compileCheckSubClass):
2292         * jit/AssemblyHelpers.h:
2293         (JSC::AssemblyHelpers::emitAllocateDestructibleObject):
2294         * jit/ThunkGenerators.cpp:
2295         (JSC::virtualThunkFor):
2296         (JSC::boundThisNoArgsFunctionCallGenerator):
2297         * runtime/JSCPoison.h:
2298         * runtime/JSDestructibleObject.h:
2299         (JSC::JSDestructibleObject::classInfo const):
2300         * runtime/JSSegmentedVariableObject.h:
2301         (JSC::JSSegmentedVariableObject::classInfo const):
2302         * runtime/Structure.h:
2303         * runtime/VM.h:
2304         * wasm/WasmB3IRGenerator.cpp:
2305         (JSC::Wasm::B3IRGenerator::addCall):
2306         (JSC::Wasm::B3IRGenerator::addCallIndirect):
2307         * wasm/WasmBinding.cpp:
2308         (JSC::Wasm::wasmToWasm):
2309
2310 2019-02-26  Mark Lam  <mark.lam@apple.com>
2311
2312         [Re-landing] Add some randomness into the StructureID.
2313         https://bugs.webkit.org/show_bug.cgi?id=194989
2314         <rdar://problem/47975563>
2315
2316         Reviewed by Yusuke Suzuki.
2317
2318         1. On 64-bit, the StructureID will now be encoded as:
2319
2320             ----------------------------------------------------------------
2321             | 1 Nuke Bit | 24 StructureIDTable index bits | 7 entropy bits |
2322             ----------------------------------------------------------------
2323
2324            The entropy bits are chosen at random and assigned when a StructureID is
2325            allocated.
2326
2327         2. Instead of Structure pointers, the StructureIDTable will now contain
2328            encodedStructureBits, which is encoded as such:
2329
2330             ----------------------------------------------------------------
2331             | 7 entropy bits |                   57 structure pointer bits |
2332             ----------------------------------------------------------------
2333
2334            The entropy bits here are the same 7 bits used in the encoding of the
2335            StructureID for this structure entry in the StructureIDTable.
2336
2337         3. Retrieval of the structure pointer given a StructureID is now computed as
2338            follows:
2339
2340                 index = structureID >> 7; // with arithmetic shift.
2341                 encodedStructureBits = structureIDTable[index];
2342                 structure = encodedStructureBits ^ (structureID << 57);
2343
2344             We use an arithmetic shift for the right shift because that will preserve
2345             the nuke bit in the high bit of the index if the StructureID was not
2346             decontaminated before use as expected.
2347
2348         4. Remove unused function loadArgumentWithSpecificClass() in SpecializedThunkJIT.
2349
2350         5. Define StructureIDTable::m_size to be the number of allocated StructureIDs
2351            instead of always being the same as m_capacity.
2352
2353         6. Change StructureIDTable::s_unusedID's value to 0.
2354
2355            Its previous value of unusedPointer i.e. 0xd1e7beef, does not make sense for
2356            StructureID on 64-bit.  Also, there was never any code that initializes unused
2357            IDs to the s_unusedID.  The only meaningful value for s_unusedID is 0, which
2358            is the ID we'll get when the freelist is empty, prompting a resize of the
2359            structureIDTable.
2360
2361         This patch appears to be perf neutral on JetStream 2 run via the cli on a
2362         11" MacBook Air, 13" MacBook Pro, iPhone 6S, and iPhone XR.
2363
2364         * ftl/FTLLowerDFGToB3.cpp:
2365         (JSC::FTL::DFG::LowerDFGToB3::loadStructure):
2366         * heap/SlotVisitor.cpp:
2367         (JSC::SlotVisitor::appendJSCellOrAuxiliary):
2368         * jit/AssemblyHelpers.cpp:
2369         (JSC::AssemblyHelpers::emitLoadStructure):
2370         * jit/AssemblyHelpers.h:
2371         * jit/SpecializedThunkJIT.h:
2372         (JSC::SpecializedThunkJIT::loadArgumentWithSpecificClass): Deleted.
2373         * llint/LowLevelInterpreter.asm:
2374         * llint/LowLevelInterpreter64.asm:
2375         * runtime/StructureIDTable.cpp:
2376         (JSC::StructureIDTable::StructureIDTable):
2377         (JSC::StructureIDTable::makeFreeListFromRange):
2378         (JSC::StructureIDTable::resize):
2379         (JSC::StructureIDTable::allocateID):
2380         (JSC::StructureIDTable::deallocateID):
2381         * runtime/StructureIDTable.h:
2382         (JSC::StructureIDTable::decode):
2383         (JSC::StructureIDTable::encode):
2384         (JSC::StructureIDTable::get):
2385         (JSC::StructureIDTable::isValid):
2386
2387 2019-02-26  Ryan Haddad  <ryanhaddad@apple.com>
2388
2389         Unreviewed, rolling out r242071.
2390
2391         Breaks internal builds.
2392
2393         Reverted changeset:
2394
2395         "Add some randomness into the StructureID."
2396         https://bugs.webkit.org/show_bug.cgi?id=194989
2397         https://trac.webkit.org/changeset/242071
2398
2399 2019-02-26  Guillaume Emont  <guijemont@igalia.com>
2400
2401         [JSC] Fix compilation on 32-bit platforms after r242071
2402         https://bugs.webkit.org/show_bug.cgi?id=195042
2403
2404         Reviewed by Carlos Garcia Campos.
2405
2406         * jit/AssemblyHelpers.cpp:
2407         (JSC::AssemblyHelpers::emitLoadStructure):
2408
2409 2019-02-26  Guillaume Emont  <guijemont@igalia.com>
2410
2411         [JSC] Repeat string created from Array.prototype.join() take too much memory
2412         https://bugs.webkit.org/show_bug.cgi?id=193912
2413
2414         Reviewed by Saam Barati.
2415
2416         Added a fast case in Array.prototype.join when the array is
2417         uninitialized.
2418
2419         * runtime/ArrayPrototype.cpp:
2420         (JSC::canUseFastJoin):
2421         (JSC::fastJoin):
2422         * runtime/JSStringInlines.h:
2423         (JSC::repeatCharacter): moved from StringPrototype.cpp
2424         * runtime/StringPrototype.cpp:
2425
2426 2019-02-25  Mark Lam  <mark.lam@apple.com>
2427
2428         Add some randomness into the StructureID.
2429         https://bugs.webkit.org/show_bug.cgi?id=194989
2430         <rdar://problem/47975563>
2431
2432         Reviewed by Yusuke Suzuki.
2433
2434         1. On 64-bit, the StructureID will now be encoded as:
2435
2436             ----------------------------------------------------------------
2437             | 1 Nuke Bit | 24 StructureIDTable index bits | 7 entropy bits |
2438             ----------------------------------------------------------------
2439
2440            The entropy bits are chosen at random and assigned when a StructureID is
2441            allocated.
2442
2443         2. Instead of Structure pointers, the StructureIDTable will now contain
2444            encodedStructureBits, which is encoded as such:
2445
2446             ----------------------------------------------------------------
2447             | 7 entropy bits |                   57 structure pointer bits |
2448             ----------------------------------------------------------------
2449
2450            The entropy bits here are the same 7 bits used in the encoding of the
2451            StructureID for this structure entry in the StructureIDTable.
2452
2453         3. Retrieval of the structure pointer given a StructureID is now computed as
2454            follows:
2455
2456                 index = structureID >> 7; // with arithmetic shift.
2457                 encodedStructureBits = structureIDTable[index];
2458                 structure = encodedStructureBits ^ (structureID << 57);
2459
2460             We use an arithmetic shift for the right shift because that will preserve
2461             the nuke bit in the high bit of the index if the StructureID was not
2462             decontaminated before use as expected.
2463
2464         4. Remove unused function loadArgumentWithSpecificClass() in SpecializedThunkJIT.
2465
2466         5. Define StructureIDTable::m_size to be the number of allocated StructureIDs
2467            instead of always being the same as m_capacity.
2468
2469         6. Change StructureIDTable::s_unusedID's value to 0.
2470
2471            Its previous value of unusedPointer i.e. 0xd1e7beef, does not make sense for
2472            StructureID on 64-bit.  Also, there was never any code that initializes unused
2473            IDs to the s_unusedID.  The only meaningful value for s_unusedID is 0, which
2474            is the ID we'll get when the freelist is empty, prompting a resize of the
2475            structureIDTable.
2476
2477         This patch appears to be perf neutral on JetStream 2 run via the cli on a
2478         11" MacBook Air, 13" MacBook Pro, iPhone 6S, and iPhone XR.
2479
2480         * ftl/FTLLowerDFGToB3.cpp:
2481         (JSC::FTL::DFG::LowerDFGToB3::loadStructure):
2482         * heap/SlotVisitor.cpp:
2483         (JSC::SlotVisitor::appendJSCellOrAuxiliary):
2484         * jit/AssemblyHelpers.cpp:
2485         (JSC::AssemblyHelpers::emitLoadStructure):
2486         * jit/AssemblyHelpers.h:
2487         * jit/SpecializedThunkJIT.h:
2488         (JSC::SpecializedThunkJIT::loadArgumentWithSpecificClass): Deleted.
2489         * llint/LowLevelInterpreter.asm:
2490         * llint/LowLevelInterpreter64.asm:
2491         * runtime/StructureIDTable.cpp:
2492         (JSC::StructureIDTable::StructureIDTable):
2493         (JSC::StructureIDTable::makeFreeListFromRange):
2494         (JSC::StructureIDTable::resize):
2495         (JSC::StructureIDTable::allocateID):
2496         (JSC::StructureIDTable::deallocateID):
2497         * runtime/StructureIDTable.h:
2498         (JSC::StructureIDTable::decode):
2499         (JSC::StructureIDTable::encode):
2500         (JSC::StructureIDTable::get):
2501         (JSC::StructureIDTable::isValid):
2502
2503 2019-02-25  Yusuke Suzuki  <ysuzuki@apple.com>
2504
2505         [JSC] Revert r226885 to make SlotVisitor creation lazy
2506         https://bugs.webkit.org/show_bug.cgi?id=195013
2507
2508         Reviewed by Saam Barati.
2509
2510         We once changed SlotVisitor creation apriori to drop the lock. Also, it turns out that SlotVisitor is memory-consuming.
2511         We should defer SlotVisitor creation until it is actually required. This patch reverts r226885. Even with this patch,
2512         we still hold many SlotVisitors after we execute many parallel markers at least once. But recovering the feature of
2513         dynamically allocating SlotVisitors helps further memory optimizations in this area.
2514
2515         * heap/Heap.cpp:
2516         (JSC::Heap::Heap):
2517         (JSC::Heap::runBeginPhase):
2518         * heap/Heap.h:
2519         * heap/HeapInlines.h:
2520         (JSC::Heap::forEachSlotVisitor):
2521         (JSC::Heap::numberOfSlotVisitors):
2522         * heap/MarkingConstraintSolver.cpp:
2523         (JSC::MarkingConstraintSolver::didVisitSomething const):
2524         * heap/SlotVisitor.h:
2525
2526 2019-02-25  Saam Barati  <sbarati@apple.com>
2527
2528         testb3 and testair should test O0/O1/O2
2529         https://bugs.webkit.org/show_bug.cgi?id=194637
2530
2531         Reviewed by Mark Lam.
2532
2533         This patch makes it so that we run all tests in testair and testb3
2534         in O0, O1, and O2. However, some tests are invalid for O0 and O1.
2535         This patch makes it so we only run those tests in O2. These are
2536         often tests that assert certain optimizations have occurred. There
2537         are also a class of tests that rely on using patchpoints to stress 
2538         the register allocator into only a single valid allocation. The
2539         O0, and sometimes O1, register allocators are not always good enough
2540         to allocate such programs. To make these valid allocators to use, we rely
2541         on the FTL and Wasm to not emit such patchpoints.
2542
2543         * b3/air/testair.cpp:
2544         (main):
2545         * b3/testb3.cpp:
2546         (JSC::B3::compileProc):
2547         (JSC::B3::testAddLoadTwice):
2548         (JSC::B3::testMulLoadTwice):
2549         (JSC::B3::testSimplePatchpointWithOuputClobbersGPArgs):
2550         (JSC::B3::testSimplePatchpointWithOuputClobbersFPArgs):
2551         (JSC::B3::testPatchpointWithEarlyClobber):
2552         (JSC::B3::testSimpleCheck):
2553         (JSC::B3::testCheckFalse):
2554         (JSC::B3::testCheckTrue):
2555         (JSC::B3::testCheckLessThan):
2556         (JSC::B3::testCheckMegaCombo):
2557         (JSC::B3::testCheckTrickyMegaCombo):
2558         (JSC::B3::testCheckTwoMegaCombos):
2559         (JSC::B3::testCheckTwoNonRedundantMegaCombos):
2560         (JSC::B3::testCheckAddImm):
2561         (JSC::B3::testCheckAddImmCommute):
2562         (JSC::B3::testCheckAddImmSomeRegister):
2563         (JSC::B3::testCheckAdd):
2564         (JSC::B3::testCheckAdd64):
2565         (JSC::B3::testCheckAddFold):
2566         (JSC::B3::testCheckAddFoldFail):
2567         (JSC::B3::testCheckAddSelfOverflow64):
2568         (JSC::B3::testCheckAddSelfOverflow32):
2569         (JSC::B3::testCheckSubImm):
2570         (JSC::B3::testCheckSubBadImm):
2571         (JSC::B3::testCheckSub):
2572         (JSC::B3::testCheckSub64):
2573         (JSC::B3::testCheckSubFold):
2574         (JSC::B3::testCheckSubFoldFail):
2575         (JSC::B3::testCheckNeg):
2576         (JSC::B3::testCheckNeg64):
2577         (JSC::B3::testCheckMul):
2578         (JSC::B3::testCheckMulMemory):
2579         (JSC::B3::testCheckMul2):
2580         (JSC::B3::testCheckMul64):
2581         (JSC::B3::testCheckMulFold):
2582         (JSC::B3::testCheckMulFoldFail):
2583         (JSC::B3::testCheckMul64SShr):
2584         (JSC::B3::testLinearScanWithCalleeOnStack):
2585         (JSC::B3::testCheckSelect):
2586         (JSC::B3::testCheckSelectCheckSelect):
2587         (JSC::B3::testCheckSelectAndCSE):
2588         (JSC::B3::testLateRegister):
2589         (JSC::B3::testReduceStrengthCheckBottomUseInAnotherBlock):
2590         (JSC::B3::testSomeEarlyRegister):
2591         (JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled2):
2592         (JSC::B3::testPinRegisters):
2593         (JSC::B3::testX86LeaAddAddShlLeft):
2594         (JSC::B3::testX86LeaAddAddShlRight):
2595         (JSC::B3::testX86LeaAddAdd):
2596         (JSC::B3::testX86LeaAddShlRight):
2597         (JSC::B3::testX86LeaAddShlLeftScale1):
2598         (JSC::B3::testX86LeaAddShlLeftScale2):
2599         (JSC::B3::testX86LeaAddShlLeftScale4):
2600         (JSC::B3::testX86LeaAddShlLeftScale8):
2601         (JSC::B3::testLoadBaseIndexShift2):
2602         (JSC::B3::testOptimizeMaterialization):
2603         (JSC::B3::testLICMPure):
2604         (JSC::B3::testLICMPureSideExits):
2605         (JSC::B3::testLICMPureWritesPinned):
2606         (JSC::B3::testLICMPureWrites):
2607         (JSC::B3::testLICMReadsPinned):
2608         (JSC::B3::testLICMReads):
2609         (JSC::B3::testLICMPureNotBackwardsDominant):
2610         (JSC::B3::testLICMPureNotBackwardsDominantFoiledByChild):
2611         (JSC::B3::testLICMControlDependent):
2612         (JSC::B3::testLICMControlDependentNotBackwardsDominant):
2613         (JSC::B3::testLICMReadsWritesDifferentHeaps):
2614         (JSC::B3::testWasmBoundsCheck):
2615         (JSC::B3::run):
2616         (main):
2617
2618 2019-02-25  Yusuke Suzuki  <ysuzuki@apple.com>
2619
2620         [JSC] stress/function-constructor-reading-from-global-lexical-environment.js fails in 32bit arch
2621         https://bugs.webkit.org/show_bug.cgi?id=195030
2622         <rdar://problem/48385088>
2623
2624         Reviewed by Saam Barati.
2625
2626         While LLInt64 has checkTDZInGlobalPutToScopeIfNecessary for op_put_to_scope GlobalLexicalVar to check the value in the variable slot is not empty,
2627         this check is missing in LLInt32_64. Previously, this check was subsumed accidentally by the WatchpointSet check in GlobalLexicalVar in `notifyWrite`:
2628         because no "put" attempt succeeds here, the status WatchpointSet was ClearWatchpoint, we always go to the slow path, and we always throw the TDZ error
2629         before configuring the WatchpointSet in the slow path. But after r241862, WatchpointSet is not used under non-JIT configuration. This skips WatchpointSet
2630         check and LLInt32_64 starts failing tests because of lack of checkTDZInGlobalPutToScopeIfNecessary. This patch adds checkTDZInGlobalPutToScopeIfNecessary
2631         in LLInt32_64 too. This patch fixes the following four failing tests.
2632
2633             stress/function-constructor-reading-from-global-lexical-environment.js.bytecode-cache
2634             stress/function-constructor-reading-from-global-lexical-environment.js.default
2635             stress/global-lexical-variable-tdz.js.bytecode-cache
2636             stress/global-lexical-variable-tdz.js.default
2637
2638         * llint/LowLevelInterpreter32_64.asm:
2639
2640 2019-02-25  Yusuke Suzuki  <ysuzuki@apple.com>
2641
2642         [JSC] Make Intl fields lazily-allocated
2643         https://bugs.webkit.org/show_bug.cgi?id=195022
2644
2645         Reviewed by Mark Lam.
2646
2647         This patch makes the following memory footprint optimization in IntlObject.
2648
2649         1. Make IntlObject fields including Intl.Collator lazily-allocated because we already removed direct references from JS builtins to these constructors (@Collator etc.).
2650
2651         2. Move LazyProperty<IntlObject, Structure> structures from IntlObject to JSGlobalObject. This makes sizeof(IntlObject) the same to the other ones of usual runtime Objects,
2652            and drop one MarkedBlock.
2653
2654         * runtime/IntlCollatorConstructor.h:
2655         * runtime/IntlDateTimeFormatConstructor.h:
2656         * runtime/IntlNumberFormatConstructor.h:
2657         * runtime/IntlObject.cpp:
2658         (JSC::createCollatorConstructor):
2659         (JSC::createNumberFormatConstructor):
2660         (JSC::createDateTimeFormatConstructor):
2661         (JSC::createPluralRulesConstructor):
2662         (JSC::IntlObject::finishCreation):
2663         (JSC::IntlObject::visitChildren): Deleted.
2664         * runtime/IntlObject.h:
2665         * runtime/IntlPluralRulesConstructor.h:
2666         * runtime/JSGlobalObject.cpp:
2667         (JSC::JSGlobalObject::init):
2668         (JSC::JSGlobalObject::visitChildren):
2669         (JSC::JSGlobalObject::defaultCollator):
2670         * runtime/JSGlobalObject.h:
2671         (JSC::JSGlobalObject::collatorStructure):
2672         (JSC::JSGlobalObject::numberFormatStructure):
2673         (JSC::JSGlobalObject::dateTimeFormatStructure):
2674         (JSC::JSGlobalObject::pluralRulesStructure):
2675         (JSC::JSGlobalObject::intlObject const): Deleted.
2676         * runtime/JSGlobalObjectFunctions.cpp:
2677         (JSC::globalFuncDateTimeFormat):
2678         * runtime/NumberPrototype.cpp:
2679         (JSC::numberProtoFuncToLocaleString):
2680         * runtime/StringPrototype.cpp:
2681         (JSC::stringProtoFuncLocaleCompare):
2682
2683 2019-02-25  Tadeu Zagallo  <tzagallo@apple.com>
2684
2685         Avoid hashing CompactVariableEnvironment when decoding CompactVariableMap::Handle
2686         https://bugs.webkit.org/show_bug.cgi?id=194937
2687
2688         Reviewed by Saam Barati.
2689
2690         Hashing the CompactVariableEnvironment is expensive and we could avoid it
2691         when decoding multiple handles to the same environment. This is sound because
2692         a pointer to the same CompactVariableEnvironment will hash the same.
2693
2694         * runtime/CachedTypes.cpp:
2695         (JSC::Decoder::handleForEnvironment const):
2696         (JSC::Decoder::setHandleForEnvironment):
2697         (JSC::CachedCompactVariableMapHandle::decode const):
2698
2699 2019-02-25  Tadeu Zagallo  <tzagallo@apple.com>
2700
2701         Remove unnecessary WTF:: prefixes in CachedTypes
2702         https://bugs.webkit.org/show_bug.cgi?id=194936
2703
2704         Reviewed by Saam Barati.
2705
2706         Cleanup unnecessary prefixes from Optional, roundUpToMultipleOf and
2707         pageSize.
2708
2709         * runtime/CachedTypes.cpp:
2710         (JSC::Encoder::cachedOffsetForPtr):
2711         (JSC::Encoder::Page::malloc):
2712         (JSC::Encoder::allocateNewPage):
2713         (JSC::CachedPtr::encode):
2714         (JSC::CachedPtr::decode const):
2715         (JSC::CachedOptional::encode):
2716         (JSC::CachedOptional::decode const):
2717
2718 2019-02-25  Yusuke Suzuki  <ysuzuki@apple.com>
2719
2720         [JSC] Drop direct references to Intl constructors by rewriting Intl JS builtins in C++
2721         https://bugs.webkit.org/show_bug.cgi?id=194976
2722
2723         Reviewed by Michael Saboff.
2724
2725         This patch paves the way to making IntlObject allocation lazy by removing direct references
2726         to Intl constructors (Intl.Collator etc.) from builtin JS. To achieve that,
2727
2728         1. We implement String.prototype.toLocaleCompare and Number.prototype.toLocaleString in C++
2729            instead of JS builtins. Since these functions end up calling ICU C++ runtime, writing them in
2730            JS does not offer performance improvement.
2731
2732         2. We remove @DateTimeFormat constructor reference, and instead, exposing @dateTimeFormat function,
2733            which returns formatted string directly. We still have JS builtins for DateTimeFormat things
2734            because the initialization of its "options" JSObject involves many get_by_id / put_by_id things,
2735            which are efficient in JS. But we avoid exposing @DateTimeFormat directly, so that Intl constructors
2736            can be lazily allocated.
2737
2738         * CMakeLists.txt:
2739         * DerivedSources-input.xcfilelist:
2740         * DerivedSources.make:
2741         * JavaScriptCore.xcodeproj/project.pbxproj:
2742         * builtins/BuiltinNames.h:
2743         * builtins/DatePrototype.js:
2744         (toLocaleString):
2745         (toLocaleDateString):
2746         (toLocaleTimeString):
2747         * builtins/NumberPrototype.js: Removed.
2748         * builtins/StringPrototype.js:
2749         (intrinsic.StringPrototypeReplaceIntrinsic.replace):
2750         (globalPrivate.getDefaultCollator): Deleted.
2751         * runtime/JSGlobalObject.cpp:
2752         (JSC::JSGlobalObject::init):
2753         (JSC::JSGlobalObject::visitChildren):
2754         (JSC::JSGlobalObject::defaultCollator):
2755         * runtime/JSGlobalObject.h:
2756         * runtime/JSGlobalObjectFunctions.cpp:
2757         (JSC::globalFuncDateTimeFormat):
2758         * runtime/JSGlobalObjectFunctions.h:
2759         * runtime/NumberPrototype.cpp:
2760         (JSC::NumberPrototype::finishCreation):
2761         (JSC::throwVMToThisNumberError):
2762         (JSC::numberProtoFuncToExponential):
2763         (JSC::numberProtoFuncToFixed):
2764         (JSC::numberProtoFuncToPrecision):
2765         (JSC::numberProtoFuncToString):
2766         (JSC::numberProtoFuncToLocaleString):
2767         (JSC::numberProtoFuncValueOf):
2768         * runtime/StringPrototype.cpp:
2769         (JSC::StringPrototype::finishCreation):
2770         (JSC::stringProtoFuncLocaleCompare):
2771
2772 2019-02-24  Devin Rousso  <drousso@apple.com>
2773
2774         Web Inspector: Change the InspectorOverlay to use native rather than canvas
2775         https://bugs.webkit.org/show_bug.cgi?id=105023
2776         <rdar://problem/13443692>
2777
2778         Reviewed by Brian Burg.
2779
2780         * inspector/protocol/OverlayTypes.json: Removed.
2781         Now that the overlay is entirely generated in C++, we no longer need the special prototol
2782         types for transferring data to a JavaScript context.
2783
2784         * inspector/protocol/Debugger.json:
2785         * inspector/agents/InspectorDebuggerAgent.h:
2786         * inspector/agents/InspectorDebuggerAgent.cpp:
2787         (Inspector::InspectorDebuggerAgent::setOverlayMessage): Deleted.
2788         Remove `Debugger.setOverlayMessage` command as it hasn't been used and is no longer supported.
2789
2790         * CMakeLists.txt:
2791         * DerivedSources-input.xcfilelist:
2792         * DerivedSources.make:
2793
2794 2019-02-24  Yusuke Suzuki  <ysuzuki@apple.com>
2795
2796         [JSC] Lazily create sentinel Map and Set buckets
2797         https://bugs.webkit.org/show_bug.cgi?id=194975
2798
2799         Reviewed by Saam Barati.
2800
2801         If VM::canUseJIT() returns false, we can lazily initialize sentinel Map and Set buckets.
2802         This patch adds getters to VM which lazily allocate these buckets. We eagerly initialize
2803         them if VM::canUseJIT() returns true since they can be touched from DFG and FTL.
2804
2805         * bytecode/BytecodeIntrinsicRegistry.cpp:
2806         (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
2807         (JSC::BytecodeIntrinsicRegistry::sentinelMapBucketValue):
2808         (JSC::BytecodeIntrinsicRegistry::sentinelSetBucketValue):
2809         * bytecode/BytecodeIntrinsicRegistry.h:
2810         * dfg/DFGByteCodeParser.cpp:
2811         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
2812         * dfg/DFGOperations.cpp:
2813         * dfg/DFGSpeculativeJIT.cpp:
2814         (JSC::DFG::SpeculativeJIT::compileGetMapBucketNext):
2815         * dfg/DFGSpeculativeJIT64.cpp:
2816         (JSC::DFG::SpeculativeJIT::compile):
2817         * ftl/FTLLowerDFGToB3.cpp:
2818         (JSC::FTL::DFG::LowerDFGToB3::compileGetMapBucket):
2819         (JSC::FTL::DFG::LowerDFGToB3::compileGetMapBucketNext):
2820         * runtime/MapConstructor.cpp:
2821         (JSC::mapPrivateFuncMapBucketNext):
2822         * runtime/SetConstructor.cpp:
2823         (JSC::setPrivateFuncSetBucketNext):
2824         * runtime/VM.cpp:
2825         (JSC::VM::VM):
2826         (JSC::VM::sentinelSetBucketSlow):
2827         (JSC::VM::sentinelMapBucketSlow):
2828         * runtime/VM.h:
2829         (JSC::VM::sentinelSetBucket):
2830         (JSC::VM::sentinelMapBucket):
2831
2832 2019-02-20  Darin Adler  <darin@apple.com>
2833
2834         Finish removing String::format
2835         https://bugs.webkit.org/show_bug.cgi?id=194893
2836
2837         Reviewed by Daniel Bates.
2838
2839         * bytecode/CodeBlock.cpp:
2840         (JSC::CodeBlock::nameForRegister): Use makeString instead of String::format,
2841         using the new "pad" function.
2842
2843 2019-02-23  Robin Morisset  <rmorisset@apple.com>
2844
2845         Remove dead code: AdjacencyList::justOneChild()
2846         https://bugs.webkit.org/show_bug.cgi?id=194965
2847
2848         Reviewed by Sam Weinig.
2849
2850         * dfg/DFGAdjacencyList.h:
2851         (JSC::DFG::AdjacencyList::justOneChild const): Deleted.
2852
2853 2019-02-23  Michael Catanzaro  <mcatanzaro@igalia.com>
2854
2855         Unreviewed, fix -Wunused-param warning
2856
2857         * jsc.cpp:
2858
2859 2019-02-23  Mark Lam  <mark.lam@apple.com>
2860
2861         Add an exception check and some assertions in StringPrototype.cpp.
2862         https://bugs.webkit.org/show_bug.cgi?id=194962
2863         <rdar://problem/48013416>
2864
2865         Reviewed by Yusuke Suzuki and Saam Barati.
2866
2867         * runtime/StringPrototype.cpp:
2868         (JSC::jsSpliceSubstrings):
2869         (JSC::jsSpliceSubstringsWithSeparators):
2870         (JSC::operationStringProtoFuncReplaceRegExpEmptyStr):
2871
2872 2019-02-23  Keith Miller  <keith_miller@apple.com>
2873
2874         Add new mac target numbers
2875         https://bugs.webkit.org/show_bug.cgi?id=194955
2876
2877         Reviewed by Tim Horton.
2878
2879         * Configurations/Base.xcconfig:
2880         * Configurations/DebugRelease.xcconfig:
2881
2882 2019-02-22  Robin Morisset  <rmorisset@apple.com>
2883
2884         DFGBytecodeParser should not declare that a node won't clobberExit if DFGFixupPhase can later declare it does clobberExit
2885         https://bugs.webkit.org/show_bug.cgi?id=194953
2886         <rdar://problem/47595253>
2887
2888         Reviewed by Saam Barati.
2889
2890         For each node that
2891         (a) may or may not clobberExit depending on their arrayMode
2892         (b) and get their arrayMode from profiling information in DFGBytecodeParser
2893         (c) and can have their arrayMode refined by DFGFixupPhase,
2894         We must make sure to be conservative in the DFGBytecodeParser and treat it as if it unconditionnally clobbered the exit.
2895         Otherwise we will hit a validation failure after fixup if the next node was marked ExitValid and exits to the same semantic origin.
2896
2897         The list of nodes that fit (a) is:
2898         - StringCharAt
2899         - HasIndexProperty
2900         - GetByVal
2901         - PutByValDirect
2902         - PutByVal
2903         - PutByValAlias
2904         - GetIndexedPropertyStorage
2905
2906         Out of these, the following also fit (b) and (c):
2907         - HasIndexedProperty
2908         - GetByVal
2909         - PutByValDirect
2910         - PutByVal
2911
2912         GetByVal already had "m_exitOK = false; // GetByVal must be treated as if it clobbers exit state, since FixupPhase may make it generic."
2913         So we just have to fix the other three the same way.
2914
2915         * dfg/DFGByteCodeParser.cpp:
2916         (JSC::DFG::ByteCodeParser::parseBlock):
2917         (JSC::DFG::ByteCodeParser::handlePutByVal):
2918
2919 2019-02-22  Robin Morisset  <rmorisset@apple.com>
2920
2921         B3ReduceStrength: missing peephole optimizations for binary operations
2922         https://bugs.webkit.org/show_bug.cgi?id=194252
2923
2924         Reviewed by Saam Barati.
2925
2926         Adds several sets of optimizations for BitAnd, BitOr and BitXor.
2927         Using BitAnd distributivity over BitOr and BitXor:
2928           Turn any of these (for Op == BitOr || Op == BitXor):
2929                 Op(BitAnd(x1, x2), BitAnd(x1, x3))
2930                 Op(BitAnd(x2, x1), BitAnd(x1, x3))
2931                 Op(BitAnd(x1, x2), BitAnd(x3, x1))
2932                 Op(BitAnd(x2, x1), BitAnd(x3, x1))
2933            Into this: BitAnd(Op(x2, x3), x1)
2934            And any of these:
2935                 Op(BitAnd(x1, x2), x1)
2936                 Op(BitAnd(x2, x1), x1)
2937                 Op(x1, BitAnd(x1, x2))
2938                 Op(x1, BitAnd(x2, x1))
2939            Into this: BitAnd(Op(x2, x1), x1)
2940            This second set is equivalent to doing x1 => BitAnd(x1, x1), and then applying the first set.
2941         Using de Morgan laws (we represent not as BitXor with allOnes):
2942           BitAnd(BitXor(x1, allOnes), BitXor(x2, allOnes)) => BitXor(BitOr(x1, x2), allOnes)
2943           BitOr(BitXor(x1, allOnes), BitXor(x2, allOnes) => BitXor(BitAnd(x1, x2), allOnes)
2944           BitOr(BitXor(x, allOnes), c) => BitXor(BitAnd(x, ~c), allOnes)
2945           BitAnd(BitXor(x, allOnes), c) => BitXor(BitOr(x, ~c), allOnes)
2946         The latter two are equivalent to doing c => BitXor(~c, allOnes), and then applying the former two.
2947
2948         All of these transformations either reduce the number of operations (which we always do when possible), or bring the expression closer to having:
2949           - BitXor with all ones at the outermost
2950           - then BitAnd
2951           - then other BitXor
2952           - then BitOr at the innermost.
2953         These transformations that don't directly reduce the number of operations are still useful for normalization (helping things like CSE), and also can enable
2954         more optimizations (for example BitXor with all ones can easily cancel each other once they are all at the outermost level).
2955
2956         * b3/B3ReduceStrength.cpp:
2957         * b3/testb3.cpp:
2958         (JSC::B3::testBitAndNotNot):
2959         (JSC::B3::testBitAndNotImm):
2960         (JSC::B3::testBitOrAndAndArgs):
2961         (JSC::B3::testBitOrAndSameArgs):
2962         (JSC::B3::testBitOrNotNot):
2963         (JSC::B3::testBitOrNotImm):
2964         (JSC::B3::testBitXorAndAndArgs):
2965         (JSC::B3::testBitXorAndSameArgs):
2966         (JSC::B3::run):
2967
2968 2019-02-22  Yusuke Suzuki  <ysuzuki@apple.com>
2969
2970         [JSC] putNonEnumerable in JSWrapperMap is too costly
2971         https://bugs.webkit.org/show_bug.cgi?id=194935
2972
2973         Reviewed by Mark Lam.
2974
2975         When we convert Objective-C blocks to JS objects, we need to set up a corresponding function object correctly.
2976         During this allocation, we call [JSValue defineProperty:descriptor] to connect a "prototype" object and "constructor" object.
2977         The problem is that this API has a particularly costly implementation:
2978
2979             [[_context globalObject][@"Object"] invokeMethod:@"defineProperty" withArguments:@[ self, key, descriptor ]];
2980
2981         This wraps each JS objects appear in this code with Objective-C wrapper. And we convert a NSDictionary to JSObject, which
2982         has "writable", "enumerable", "configurable", "value" fields, and call the "defineProperty" JS function through Objective-C wrapper.
2983         This allocates many Objective-C wrappers and JS objects for descriptors. Since JSC has a direct C++ API "defineOwnProperty", we should
2984         bypass these Objective-C APIs and call JSC's code directly.
2985
2986         This patch changes `putNonEnumerable` implementation, from calling [JSValue defineProperty:descriptor] to calling JSC C++ code directly.
2987         We do not change [JSValue defineProperty:descriptor] implementation for now because of two reasons. (1) This is not used in our benchmarks
2988         except for this (converting an Objective-C block to a JS object) one path. And (2) even if we were to re-write [JSValue defineProperty:descriptor]
2989         to be more optimized, we would still want to call the JSC C++ version of defineProperty directly here to avoid NSDictionary allocation for a descriptor.
2990
2991         * API/APIUtils.h:
2992         (setException):
2993         * API/JSWrapperMap.mm:
2994         (putNonEnumerable):
2995         (copyMethodsToObject):
2996         (-[JSObjCClassInfo allocateConstructorAndPrototypeInContext:]):
2997         (-[JSObjCClassInfo wrapperForObject:inContext:]):
2998
2999 2019-02-22  Yusuke Suzuki  <ysuzuki@apple.com>
3000
3001         Unreviewed, build fix after r241954
3002         https://bugs.webkit.org/show_bug.cgi?id=194939
3003
3004         Renaming setCanAccessHeap was incomplete.
3005
3006         * runtime/SmallStrings.cpp:
3007         (JSC::SmallStrings::initializeCommonStrings):
3008         * runtime/VM.cpp:
3009         (JSC::VM::~VM):
3010
3011 2019-02-22  Yusuke Suzuki  <ysuzuki@apple.com>
3012
3013         [JSC] SmallStringsStorage is unnecessary
3014         https://bugs.webkit.org/show_bug.cgi?id=194939
3015
3016         Reviewed by Mark Lam.
3017
3018         SmallStrings hold common small JSStrings. Their underlying StringImpl is also held by SmallStringsStorage.
3019         But it is duplicate since we can get StringImpl from small JSStrings. This patch removes SmallStringsStorage,
3020         and get StringImpls from JSStrings if necessary.
3021
3022         We also add m_canAccessHeap flag to SmallStrings. At the time of VM destruction, JSStrings are destroyed when
3023         VM's Heap is finalized. We must not touch JSStrings before VM's heap (and JSStrings in SmallStrings) is initialized,
3024         and after VM's Heap is destroyed. We add this m_canAccessHeap flag to allow users to get StringImpl during the
3025         this sensitive period. If m_canAccessHeap is false, we get StringImpl from AtomicStringImpl::add.
3026
3027         * runtime/SmallStrings.cpp:
3028         (JSC::SmallStrings::initializeCommonStrings):
3029         (JSC::SmallStrings::singleCharacterStringRep):
3030         (JSC::SmallStringsStorage::rep): Deleted.
3031         (JSC::SmallStringsStorage::SmallStringsStorage): Deleted.
3032         (JSC::SmallStrings::createSingleCharacterString): Deleted.
3033         * runtime/SmallStrings.h:
3034         (JSC::SmallStrings::setCanAccessHeap):
3035         * runtime/VM.cpp:
3036         (JSC::VM::VM):
3037         (JSC::VM::~VM):
3038
3039 2019-02-22  Tadeu Zagallo  <tzagallo@apple.com>
3040
3041         Cache CompactVariableMap::Handle instead of VariableEnvironment for UnlinkedFunctionExecutable
3042         https://bugs.webkit.org/show_bug.cgi?id=194706
3043
3044         Reviewed by Saam Barati.
3045
3046         In https://bugs.webkit.org/show_bug.cgi?id=194583 we started using a
3047         CompactVariableMap::Handle instead of VariableEnvironment for
3048         UnlinkedFunctionExecutables, but we were creating the full environment
3049         to encode the executable in the bytecode cache. This patch changes it so
3050         that we cache the handle instead of the environment. This avoids duplicating
3051         the VariableEnvironment whenever we have to cache two handles that point
3052         to the environment.
3053
3054         * bytecode/UnlinkedFunctionExecutable.h:
3055         * parser/VariableEnvironment.cpp:
3056         (JSC::CompactVariableMap::get):
3057         * parser/VariableEnvironment.h:
3058         * runtime/CachedTypes.cpp:
3059         (JSC::CachedCompactVariableEnvironment::encode):
3060         (JSC::CachedCompactVariableEnvironment::decode const):
3061         (JSC::CachedCompactVariableMapHandle::encode):
3062         (JSC::CachedCompactVariableMapHandle::decode const):
3063         (JSC::CachedFunctionExecutable::encode):
3064         (JSC::CachedFunctionExecutable::decode const):
3065         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
3066
3067 2019-02-21  Saam Barati  <sbarati@apple.com>
3068
3069         Update JSScript SPI based on feedback
3070         https://bugs.webkit.org/show_bug.cgi?id=194517
3071
3072         Reviewed by Keith Miller.
3073
3074         This patch updates the JSScript SPI in the following ways:
3075         - JSScript can now represent both modules and programs. This is a property
3076         of the script determined during creation.
3077         - JSScript now takes a sourceURL during construction. For modules, this acts
3078         as the module identifier.
3079         - JSScript now has SPI for writing the cache out to disk. We don't do this
3080         automatically.
3081         - JSScript will load the bytecode cache on creation if it exists.
3082         - We retrofit these new requirements on the prior JSScript SPI that
3083         we're going to remove as soon as we can: https://bugs.webkit.org/show_bug.cgi?id=194909.
3084         Previous SPI assumes all JSScripts are modules. Previous SPI also assigns
3085         a sourceURL to the JSScript based on what the module loader decided the
3086         identifier should be. We'll remove this once we remove the old SPI.
3087         
3088         This patch also adds SPI to JSContext to evaluate a JSScript. For modules,
3089         this is like returning the result of doing dynamic import. For programs,
3090         this does normal program evaluation.
3091         
3092         This patch also fixes a bug in generateBytecode/generateModuleBytecode where
3093         we would try to cache the bytecode even if recursivelyGenerateUnlinkedCodeBlock
3094         returned null. E.g, if the script had a syntax error.
3095         
3096         When writing tests, I also discovered that someone previously broke
3097         testapi. This patch also fixes those failures. They were broken when
3098         we switched to using a testapiScripts directory to hold our test .js
3099         scripts. 
3100
3101         * API/JSAPIGlobalObject.h:
3102         * API/JSAPIGlobalObject.mm:
3103         (JSC::JSAPIGlobalObject::moduleLoaderResolve):
3104         (JSC::JSAPIGlobalObject::moduleLoaderFetch):
3105         (JSC::JSAPIGlobalObject::loadAndEvaluateJSScriptModule):
3106         * API/JSBase.cpp:
3107         (JSEvaluateScriptInternal):
3108         (JSEvaluateScript):
3109         * API/JSBaseInternal.h: Added.
3110         * API/JSContext.mm:
3111         (-[JSContext evaluateScript:withSourceURL:]):
3112         (-[JSContext evaluateJSScript:]):
3113         * API/JSContextPrivate.h:
3114         * API/JSScript.h:
3115         * API/JSScript.mm:
3116         (+[JSScript scriptWithSource:inVirtualMachine:]):
3117         (+[JSScript scriptFromASCIIFile:inVirtualMachine:withCodeSigning:andBytecodeCache:]):
3118         (createError):
3119         (+[JSScript scriptOfType:inVirtualMachine:withSourceURL:andSource:andBytecodeCache:error:]):
3120         (+[JSScript scriptOfType:inVirtualMachine:memoryMappedFromASCIIFile:withSourceURL:andBytecodeCache:error:]):
3121         (-[JSScript cacheBytecodeWithError:]):
3122         (-[JSScript sourceURL]):
3123         (-[JSScript type]):
3124         (-[JSScript jsSourceCode]):
3125         (-[JSScript writeCache:]):
3126         (-[JSScript setSourceURL:]):
3127         (-[JSScript forceRecreateJSSourceCode]):
3128         (-[JSScript writeCache]): Deleted.
3129         (-[JSScript jsSourceCode:]): Deleted.
3130         * API/JSScriptInternal.h:
3131         * API/tests/FunctionOverridesTest.cpp:
3132         (testFunctionOverrides):
3133         * API/tests/testapi.c:
3134         (main):
3135         * API/tests/testapi.mm:
3136         (tempFile):
3137         (testModuleBytecodeCache):
3138         (testProgramBytecodeCache):
3139         (testBytecodeCacheWithSyntaxError):
3140         (testProgramJSScriptException):
3141         (testLoadBasicFileLegacySPI):
3142         (+[JSContextMemoryMappedLoaderDelegate newContext]):
3143         (-[JSContextMemoryMappedLoaderDelegate context:fetchModuleForIdentifier:withResolveHandler:andRejectHandler:]):
3144         (testLoadBasicFile):
3145         (+[JSContextAugmentedLoaderDelegate newContext]):
3146         (-[JSContextAugmentedLoaderDelegate context:fetchModuleForIdentifier:withResolveHandler:andRejectHandler:]):
3147         (testJSScriptURL):
3148         (testObjectiveCAPI):
3149         (testBytecodeCache): Deleted.
3150         * API/tests/testapiScripts/foo.js: Added.
3151         * JavaScriptCore.xcodeproj/project.pbxproj:
3152         * runtime/Completion.cpp:
3153         (JSC::generateBytecode):
3154         (JSC::generateModuleBytecode):
3155
3156 2019-02-21  Mark Lam  <mark.lam@apple.com>
3157
3158         Add more doesGC() assertions.
3159         https://bugs.webkit.org/show_bug.cgi?id=194911
3160         <rdar://problem/48285723>
3161
3162         Reviewed by Saam Barati and Yusuke Suzuki.
3163
3164         * dfg/DFGOSRExit.cpp:
3165         (JSC::DFG::OSRExit::compileOSRExit):
3166         - Set expectDoesGC here because we no longer have to worry about missing store
3167           barriers in optimized code after this point.  This will prevent false positive
3168           assertion failures arising from functions called beneath compileOSRExit().
3169
3170         (JSC::DFG::OSRExit::compileExit):
3171         - Add a comment to explain why the generated ramp needs to set expectDoesGC even
3172           though compileOSRExit() also sets it.  Reason: compileOSRExit() is only called
3173           for the first OSR from this code origin, the generated ramp is called for many
3174           subsequents OSR exits from this code origin.
3175
3176         * ftl/FTLOSRExitCompiler.cpp:
3177         (JSC::FTL::compileStub):
3178         - Added a comment for the equivalent reason to the one above.
3179
3180         (JSC::FTL::compileFTLOSRExit):
3181         - Set expectDoesGC here because we no longer have to worry about missing store
3182           barriers in optimized code after this point.  This will prevent false positive
3183           assertion failures arising from functions called beneath compileFTLOSRExit().
3184
3185         * heap/CompleteSubspace.cpp:
3186         (JSC::CompleteSubspace::tryAllocateSlow):
3187         * heap/CompleteSubspaceInlines.h:
3188         (JSC::CompleteSubspace::allocateNonVirtual):
3189         - assert expectDoesGC.
3190
3191         * heap/DeferGC.h:
3192         (JSC::DeferGC::~DeferGC):
3193         - assert expectDoesGC.
3194         - Also added WTF_FORBID_HEAP_ALLOCATION to DeferGC, DeferGCForAWhile, and DisallowGC
3195           because all 3 should be stack allocated RAII objects.
3196
3197         * heap/GCDeferralContext.h:
3198         * heap/GCDeferralContextInlines.h:
3199         (JSC::GCDeferralContext::~GCDeferralContext):
3200         - Added WTF_FORBID_HEAP_ALLOCATION.
3201         - assert expectDoesGC.
3202
3203         * heap/Heap.cpp:
3204         (JSC::Heap::collectNow):
3205         (JSC::Heap::collectAsync):
3206         (JSC::Heap::collectSync):
3207         (JSC::Heap::stopIfNecessarySlow):
3208         (JSC::Heap::collectIfNecessaryOrDefer):
3209         * heap/HeapInlines.h:
3210         (JSC::Heap::acquireAccess):
3211         (JSC::Heap::stopIfNecessary):
3212         * heap/LargeAllocation.cpp:
3213         (JSC::LargeAllocation::tryCreate):
3214         * heap/LocalAllocatorInlines.h:
3215         (JSC::LocalAllocator::allocate):
3216         - conservatively assert expectDoesGC on these functions that may trigger a GC
3217           though they don't always do.
3218
3219         * runtime/DisallowScope.h:
3220         - DisallowScope should be stack allocated because it's an RAII object.
3221
3222         * runtime/JSCellInlines.h:
3223         (JSC::tryAllocateCellHelper):
3224         - Remove the expectDoesGC assertion because it is now covered by assertions in
3225           CompleteSubspace, LargeAllocation, and LocalAllocator.
3226
3227         * runtime/RegExpMatchesArray.h:
3228         (JSC::createRegExpMatchesArray):
3229         - assert expectDoesGC.
3230
3231 2019-02-21  Yusuke Suzuki  <ysuzuki@apple.com>
3232
3233         [JSC] Use Fast Malloc as much as possible
3234         https://bugs.webkit.org/show_bug.cgi?id=194316
3235
3236         Reviewed by Mark Lam.
3237
3238         We should use Fast Malloc as much as possible to offer the whole memory view to bmalloc.
3239
3240         * inspector/scripts/codegen/cpp_generator_templates.py:
3241         * inspector/scripts/tests/all/expected/definitions-with-mac-platform.json-result:
3242         * inspector/scripts/tests/generic/expected/enum-values.json-result:
3243         * inspector/scripts/tests/generic/expected/events-with-optional-parameters.json-result:
3244         * inspector/scripts/tests/generic/expected/generate-domains-with-feature-guards.json-result:
3245         * inspector/scripts/tests/mac/expected/definitions-with-mac-platform.json-result:
3246         * jit/ExecutableAllocator.h:
3247         * jsc.cpp:
3248         * runtime/JSRunLoopTimer.h:
3249         * tools/VMInspector.h:
3250         * wasm/WasmThunks.h:
3251
3252 2019-02-20  Yusuke Suzuki  <ysuzuki@apple.com>
3253
3254         [JSC] Remove WatchpointSet creation for SymbolTable entries if VM::canUseJIT() returns false
3255         https://bugs.webkit.org/show_bug.cgi?id=194891
3256
3257         Reviewed by Geoffrey Garen.
3258
3259         WatchpointSet in SymbolTable is used to fold the value into a constant in JIT tiers. And it is
3260         not useful under the non-JIT mode. This patch avoids creation of WatchpointSet in SymbolTable
3261         if VM::canUseJIT() returns false.
3262
3263         * llint/LowLevelInterpreter32_64.asm:
3264         * llint/LowLevelInterpreter64.asm:
3265         * runtime/SymbolTable.cpp:
3266         (JSC::SymbolTableEntry::addWatchpoint): Deleted.
3267         * runtime/SymbolTable.h:
3268         (JSC::SymbolTableEntry::isWatchable const):
3269         (JSC::SymbolTableEntry::watchpointSet):
3270
3271 2019-02-20  Mark Lam  <mark.lam@apple.com>
3272
3273         Add code to validate expected GC activity modelled by doesGC() against what the runtime encounters.
3274         https://bugs.webkit.org/show_bug.cgi?id=193938
3275         <rdar://problem/47616277>
3276
3277         Reviewed by Michael Saboff, Saam Barati, and Robin Morisset.
3278
3279         In DFG::SpeculativeJIT::compile() and FTL::LowerDFGToB3::compileNode(), before
3280         emitting code / B3IR for each DFG node, we emit a write to set Heap::m_expectDoesGC
3281         to the value returned by doesGC() for that node.  In the runtime (i.e. in allocateCell()
3282         and functions that can resolve a rope), we assert that Heap::m_expectDoesGC is
3283         true.
3284
3285         This validation code is currently only enabled for debug builds.  It is disabled
3286         for release builds by default, but it can easily be made to run on release builds
3287         as well by forcing ENABLE_DFG_DOES_GC_VALIDATION to 1 in Heap.h.
3288
3289         To allow this validation code to run on release builds as well, the validation uses
3290         RELEASE_ASSERT instead of ASSERT.
3291
3292         To ensure that Heap.h is #include'd for all files that needs to do this validation
3293         (so that the validation code is accidentally disabled), we guard the validation
3294         code with an if conditional on constexpr bool validateDFGDoesGC (instead of using
3295         a #if ENABLE(DFG_DOES_GC_VALIDATION)).  This way, if Heap.h isn't #include'd, the
3296         validation code will fail to build (no silent failures).
3297
3298         Currently, all JSC tests and Layout tests should pass with this validation enabled
3299         in debug builds.  We'll only see new failures if there's a regression or if new
3300         tests reveal a previously untested code path that has an undetected issue.
3301
3302         * dfg/DFGOSRExit.cpp:
3303         (JSC::DFG::OSRExit::executeOSRExit):
3304         (JSC::DFG::OSRExit::compileExit):
3305         * dfg/DFGSpeculativeJIT64.cpp:
3306         (JSC::DFG::SpeculativeJIT::compile):
3307         * ftl/FTLLowerDFGToB3.cpp:
3308         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
3309         * ftl/FTLOSRExitCompiler.cpp:
3310         (JSC::FTL::compileStub):
3311         * heap/Heap.h:
3312         (JSC::Heap::expectDoesGC const):
3313         (JSC::Heap::setExpectDoesGC):
3314         (JSC::Heap::addressOfExpectDoesGC):
3315         * jit/JITArithmetic.cpp:
3316         (JSC::JIT::emit_compareAndJump):
3317         * runtime/JSCellInlines.h:
3318         (JSC::tryAllocateCellHelper):
3319         * runtime/JSString.h:
3320         (JSC::jsSingleCharacterString):
3321         (JSC::JSString::toAtomicString const):
3322         (JSC::JSString::toExistingAtomicString const):
3323         (JSC::JSString::value const):
3324         (JSC::JSString::tryGetValue const):
3325         (JSC::JSRopeString::unsafeView const):
3326         (JSC::JSRopeString::viewWithUnderlyingString const):
3327         (JSC::JSString::unsafeView const):