Remove JSCBuiltins.cpp from Copy Headers phase
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2019-04-17  Keith Rollin  <krollin@apple.com>
2
3         Remove JSCBuiltins.cpp from Copy Headers phase
4         https://bugs.webkit.org/show_bug.cgi?id=196981
5         <rdar://problem/49952133>
6
7         Reviewed by Alex Christensen.
8
9         JSCBuiltins.cpp is not a header and so doesn't need to be in the Copy
10         Headers phase. Checking its history, it seems to have been added
11         accidentally at the same time that JSCBuiltins.h was added.
12
13         * JavaScriptCore.xcodeproj/project.pbxproj:
14
15 2019-04-16  Stephan Szabo  <stephan.szabo@sony.com>
16
17         [PlayStation] Update port for system library changes
18         https://bugs.webkit.org/show_bug.cgi?id=196978
19
20         Reviewed by Ross Kirsling.
21
22         * shell/playstation/Initializer.cpp:
23         Add reference to new posix compatibility library.
24
25 2019-04-16  Robin Morisset  <rmorisset@apple.com>
26
27         [WTF] holdLock should be marked WARN_UNUSED_RETURN
28         https://bugs.webkit.org/show_bug.cgi?id=196922
29
30         Reviewed by Keith Miller.
31
32         There was one case where holdLock was used and the result ignored.
33         From a comment that was deleted in https://bugs.webkit.org/attachment.cgi?id=328438&action=prettypatch, I believe that it is on purpose.
34         So I brought back a variant of the comment, and made the ignoring of the return explicit.
35
36         * heap/BlockDirectory.cpp:
37         (JSC::BlockDirectory::isPagedOut):
38
39 2019-04-16  Caitlin Potter  <caitp@igalia.com>
40
41         [JSC] Filter DontEnum properties in ProxyObject::getOwnPropertyNames()
42         https://bugs.webkit.org/show_bug.cgi?id=176810
43
44         Reviewed by Saam Barati.
45
46         This adds conditional logic following the invariant checks, to perform
47         filtering in common uses of getOwnPropertyNames.
48
49         While this would ideally only be done in JSPropertyNameEnumerator, adding
50         the filtering to ProxyObject::performGetOwnPropertyNames maintains the
51         invariant that the EnumerationMode is properly followed.
52
53         This was originally rolled out in r244020, as DontEnum filtering code
54         in ObjectConstructor.cpp's ownPropertyKeys() had not been removed. It's
55         now redundant due to being handled in ProxyObject::getOwnPropertyNames().
56
57         * runtime/PropertyNameArray.h:
58         (JSC::PropertyNameArray::reset):
59         * runtime/ProxyObject.cpp:
60         (JSC::ProxyObject::performGetOwnPropertyNames):
61
62 2019-04-15  Saam barati  <sbarati@apple.com>
63
64         Modify how we do SetArgument when we inline varargs calls
65         https://bugs.webkit.org/show_bug.cgi?id=196712
66         <rdar://problem/49605012>
67
68         Reviewed by Michael Saboff.
69
70         When we inline varargs calls, we guarantee that the number of arguments that
71         go on the stack are somewhere between the "mandatoryMinimum" and the "limit - 1".
72         However, we can't statically guarantee that the arguments between these two
73         ranges was filled out by Load/ForwardVarargs. This is because in the general
74         case we don't know the argument count statically.
75         
76         However, we used to always emit SetArgumentDefinitely up to "limit - 1" for
77         all arguments, even when some arguments aren't guaranteed to be in a valid
78         state. Emitting these SetArgumentDefinitely were helpful because they let us
79         handle variable liveness and OSR exit metadata. However, when we converted
80         to SSA, we ended up emitting a GetStack for each such SetArgumentDefinitely.
81         
82         This is wrong, as we can't guarantee such SetArgumentDefinitely nodes are
83         actually looking at a range of the stack that are guaranteed to be initialized.
84         This patch introduces a new form of SetArgument node: SetArgumentMaybe. In terms
85         of OSR exit metadata and variable liveness tracking, it behaves like SetArgumentDefinitely.
86         
87         However, it differs in a couple key ways:
88         1. In ThreadedCPS, GetLocal(@SetArgumentMaybe) is invalid IR, as this implies
89         you might be loading uninitialized stack. (This same rule applies when you do
90         the full data flow reachability analysis over CPS Phis.) If someone logically
91         wanted to emit code like this, the correct node to emit would be GetArgument,
92         not GetLocal. For similar reasons, PhantomLocal(@SetArgumentMaybe) is also
93         invalid IR.
94         2. To track liveness, Flush(@SetArgumentMaybe) is valid, and is the main user
95         of SetArgumentMaybe.
96         3. In SSA conversion, we don't lower SetArgumentMaybe to GetStack, as there
97         should be no data flow user of SetArgumentMaybe.
98         
99         SetArgumentDefinitely guarantees that the stack slot is initialized.
100         SetArgumentMaybe makes no such guarantee.
101
102         * dfg/DFGAbstractInterpreterInlines.h:
103         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
104         * dfg/DFGByteCodeParser.cpp:
105         (JSC::DFG::ByteCodeParser::handleVarargsInlining):
106         * dfg/DFGCPSRethreadingPhase.cpp:
107         (JSC::DFG::CPSRethreadingPhase::freeUnnecessaryNodes):
108         (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor):
109         (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor):
110         (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
111         (JSC::DFG::CPSRethreadingPhase::propagatePhis):
112         (JSC::DFG::CPSRethreadingPhase::computeIsFlushed):
113         * dfg/DFGClobberize.h:
114         (JSC::DFG::clobberize):
115         * dfg/DFGCommon.h:
116         * dfg/DFGDoesGC.cpp:
117         (JSC::DFG::doesGC):
118         * dfg/DFGFixupPhase.cpp:
119         (JSC::DFG::FixupPhase::fixupNode):
120         * dfg/DFGInPlaceAbstractState.cpp:
121         (JSC::DFG::InPlaceAbstractState::endBasicBlock):
122         * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
123         (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlockForTryCatch):
124         * dfg/DFGMaximalFlushInsertionPhase.cpp:
125         (JSC::DFG::MaximalFlushInsertionPhase::treatRegularBlock):
126         (JSC::DFG::MaximalFlushInsertionPhase::treatRootBlock):
127         * dfg/DFGMayExit.cpp:
128         * dfg/DFGNode.cpp:
129         (JSC::DFG::Node::hasVariableAccessData):
130         * dfg/DFGNodeType.h:
131         * dfg/DFGPhantomInsertionPhase.cpp:
132         * dfg/DFGPredictionPropagationPhase.cpp:
133         * dfg/DFGSSAConversionPhase.cpp:
134         (JSC::DFG::SSAConversionPhase::run):
135         * dfg/DFGSafeToExecute.h:
136         (JSC::DFG::safeToExecute):
137         * dfg/DFGSpeculativeJIT32_64.cpp:
138         (JSC::DFG::SpeculativeJIT::compile):
139         * dfg/DFGSpeculativeJIT64.cpp:
140         (JSC::DFG::SpeculativeJIT::compile):
141         * dfg/DFGValidate.cpp:
142         * ftl/FTLCapabilities.cpp:
143         (JSC::FTL::canCompile):
144
145 2019-04-15  Commit Queue  <commit-queue@webkit.org>
146
147         Unreviewed, rolling out r243672.
148         https://bugs.webkit.org/show_bug.cgi?id=196952
149
150         [JSValue release] should be thread-safe (Requested by
151         yusukesuzuki on #webkit).
152
153         Reverted changeset:
154
155         "[JSC] JSWrapperMap should not use Objective-C Weak map
156         (NSMapTable with NSPointerFunctionsWeakMemory) for
157         m_cachedObjCWrappers"
158         https://bugs.webkit.org/show_bug.cgi?id=196392
159         https://trac.webkit.org/changeset/243672
160
161 2019-04-15  Saam barati  <sbarati@apple.com>
162
163         SafeToExecute for GetByOffset/GetGetterByOffset/PutByOffset is using the wrong child for the base
164         https://bugs.webkit.org/show_bug.cgi?id=196945
165         <rdar://problem/49802750>
166
167         Reviewed by Filip Pizlo.
168
169         * dfg/DFGSafeToExecute.h:
170         (JSC::DFG::safeToExecute):
171
172 2019-04-15  Robin Morisset  <rmorisset@apple.com>
173
174         DFG should be able to constant fold Object.create() with a constant prototype operand
175         https://bugs.webkit.org/show_bug.cgi?id=196886
176
177         Reviewed by Yusuke Suzuki.
178
179
180         It is a fairly simple and limited patch, as it only works when the DFG can prove the exact object used as prototype.
181         But when it applies it can be a significant win:
182                                                         Baseline                   Optim                                       
183         object-create-constant-prototype              3.6082+-0.0979     ^      1.6947+-0.0756        ^ definitely 2.1292x faster
184         object-create-null                           11.4492+-0.2510     ?     11.5030+-0.2402        ?
185         object-create-unknown-object-prototype       15.6067+-0.1851     ?     15.7500+-0.2322        ?
186         object-create-untyped-prototype               8.8873+-0.1240     ?      8.9806+-0.1202        ? might be 1.0105x slower
187         <geometric>                                   8.6967+-0.1208     ^      7.2408+-0.1367        ^ definitely 1.2011x faster
188
189         The only subtlety is that we need to to access the StructureCache concurrently from the compiler thread (see https://bugs.webkit.org/show_bug.cgi?id=186199)
190         I solved this with a simple lock, taken when the compiler thread tries to read it, and when the main thread tries to modify it.
191         I expect it to be extremely low contention, but will watch the bots just in case.
192         The lock is taken neither when the main thread is only reading the cache (it has no-one to race with), nor when the GC purges it of dead entries (it does not free anything while a compiler thread is in the middle of a phase).
193
194         * dfg/DFGAbstractInterpreterInlines.h:
195         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
196         * dfg/DFGConstantFoldingPhase.cpp:
197         (JSC::DFG::ConstantFoldingPhase::foldConstants):
198         * runtime/StructureCache.cpp:
199         (JSC::StructureCache::createEmptyStructure):
200         (JSC::StructureCache::tryEmptyObjectStructureForPrototypeFromCompilerThread):
201         * runtime/StructureCache.h:
202
203 2019-04-15  Devin Rousso  <drousso@apple.com>
204
205         Web Inspector: fake value descriptors for promises add a catch handler, preventing "rejectionhandled" events from being fired
206         https://bugs.webkit.org/show_bug.cgi?id=196484
207         <rdar://problem/49114725>
208
209         Reviewed by Joseph Pecoraro.
210
211         Only add a catch handler when the promise is reachable via a native getter and is known to
212         have rejected. A non-rejected promise doesn't need a catch handler, and any promise that
213         isn't reachable via a getter won't actually be reached, as `InjectedScript` doesn't call any
214         functions, instead only getting the function object itself.
215
216         * inspector/InjectedScriptSource.js:
217         (InjectedScript.prototype._propertyDescriptors.createFakeValueDescriptor):
218
219         * inspector/JSInjectedScriptHost.h:
220         * inspector/JSInjectedScriptHost.cpp:
221         (Inspector::JSInjectedScriptHost::isPromiseRejectedWithNativeGetterTypeError): Added.
222         * inspector/JSInjectedScriptHostPrototype.cpp:
223         (Inspector::JSInjectedScriptHostPrototype::finishCreation):
224         (Inspector::jsInjectedScriptHostPrototypeFunctionIsPromiseRejectedWithNativeGetterTypeError): Added.
225
226         * runtime/ErrorInstance.h:
227         (JSC::ErrorInstance::setNativeGetterTypeError): Added.
228         (JSC::ErrorInstance::isNativeGetterTypeError const): Added.
229
230         * runtime/Error.h:
231         (JSC::throwVMGetterTypeError): Added.
232         * runtime/Error.cpp:
233         (JSC::createGetterTypeError): Added.
234         (JSC::throwGetterTypeError): Added.
235         (JSC::throwDOMAttributeGetterTypeError):
236
237 2019-04-15  Robin Morisset  <rmorisset@apple.com>
238
239         B3::Value should have different kinds of adjacency lists
240         https://bugs.webkit.org/show_bug.cgi?id=196091
241
242         Reviewed by Filip Pizlo.
243
244         The key idea of this optimization is to replace the Vector<Value*, 3> m_children in B3::Value (40 bytes on 64-bits platform) by one of the following:
245         - Nothing (0 bytes)
246         - 1 Value* (8 bytes)
247         - 2 Value* (16 bytes)
248         - 3 Value* (24 bytes)
249         - A Vector<Value*, 3>
250         after the end of the Value object, depending on the kind of the Value.
251         So for example, when allocating an Add, we would allocate an extra 16 bytes into which to store 2 Values.
252         This would halve the memory consumption of Const64/Const32/Nop/Identity and a bunch more kinds of values, and reduce by a more moderate amount the memory consumption of the rest of non-varargs values (e.g. Add would go from 72 to 48 bytes).
253
254         A few implementation points:
255         - Even if there is no children, we must remember to allocate at least enough space for replaceWithIdentity to work later. It needs sizeof(Value) (for the object itself) + sizeof(Value*) (for the pointer to its child)
256         - We must make sure to destroy the vector whenever we destroy a Value which is VarArgs
257         - We must remember how many elements there are in the case where we did not allocate a Vector. We cannot do it purely by relying on the kind, both for speed reasons and because Return can have either 0 or 1 argument in B3
258           Thankfully, we have an extra byte of padding to use in the middle of B3::Value
259         - In order to support clone(), we must have a separate version of allocate, which extracts the opcode from the to-be-cloned object instead of from the call to the constructor
260         - Speaking of which, we need a special templated function opcodeFromConstructor, because some of the constructors of subclasses of Value don't take an explicit Opcode as argument, typically because they match a single one.
261         - To maximize performance, we provide specialized versions of child/lastChild/numChildren/children in the subclasses of Value, skipping checks when the actual type of the Value is already known.
262           This is done through the B3_SPECIALIZE_VALUE_FOR_... defined at the bottom of B3Value.h
263         - In the constructors of Value, we convert all extra children arguments to Value* eagerly. It is not required for correctness (they will be converted when put into a Vector<Value*> or a Value* in the end), but it helps limit an explosion in the number of template instantiations.
264         - I moved DeepValueDump::dump from the .h to the .cpp, as there is no good reason to inline it, and recompiling JSC is already slow enough
265
266         * JavaScriptCore.xcodeproj/project.pbxproj:
267         * b3/B3ArgumentRegValue.cpp:
268         (JSC::B3::ArgumentRegValue::cloneImpl const): Deleted.
269         * b3/B3ArgumentRegValue.h:
270         * b3/B3AtomicValue.cpp:
271         (JSC::B3::AtomicValue::AtomicValue):
272         (JSC::B3::AtomicValue::cloneImpl const): Deleted.
273         * b3/B3AtomicValue.h:
274         * b3/B3BasicBlock.h:
275         * b3/B3BasicBlockInlines.h:
276         (JSC::B3::BasicBlock::appendNewNonTerminal): Deleted.
277         * b3/B3CCallValue.cpp:
278         (JSC::B3::CCallValue::appendArgs):
279         (JSC::B3::CCallValue::cloneImpl const): Deleted.
280         * b3/B3CCallValue.h:
281         * b3/B3CheckValue.cpp:
282         (JSC::B3::CheckValue::cloneImpl const): Deleted.
283         * b3/B3CheckValue.h:
284         * b3/B3Const32Value.cpp:
285         (JSC::B3::Const32Value::cloneImpl const): Deleted.
286         * b3/B3Const32Value.h:
287         * b3/B3Const64Value.cpp:
288         (JSC::B3::Const64Value::cloneImpl const): Deleted.
289         * b3/B3Const64Value.h:
290         * b3/B3ConstDoubleValue.cpp:
291         (JSC::B3::ConstDoubleValue::cloneImpl const): Deleted.
292         * b3/B3ConstDoubleValue.h:
293         * b3/B3ConstFloatValue.cpp:
294         (JSC::B3::ConstFloatValue::cloneImpl const): Deleted.
295         * b3/B3ConstFloatValue.h:
296         * b3/B3ConstPtrValue.h:
297         (JSC::B3::ConstPtrValue::opcodeFromConstructor):
298         * b3/B3FenceValue.cpp:
299         (JSC::B3::FenceValue::FenceValue):
300         (JSC::B3::FenceValue::cloneImpl const): Deleted.
301         * b3/B3FenceValue.h:
302         * b3/B3MemoryValue.cpp:
303         (JSC::B3::MemoryValue::MemoryValue):
304         (JSC::B3::MemoryValue::cloneImpl const): Deleted.
305         * b3/B3MemoryValue.h:
306         * b3/B3MoveConstants.cpp:
307         * b3/B3PatchpointValue.cpp:
308         (JSC::B3::PatchpointValue::cloneImpl const): Deleted.
309         * b3/B3PatchpointValue.h:
310         (JSC::B3::PatchpointValue::opcodeFromConstructor):
311         * b3/B3Procedure.cpp:
312         * b3/B3Procedure.h:
313         * b3/B3ProcedureInlines.h:
314         (JSC::B3::Procedure::add):
315         * b3/B3SlotBaseValue.cpp:
316         (JSC::B3::SlotBaseValue::cloneImpl const): Deleted.
317         * b3/B3SlotBaseValue.h:
318         * b3/B3StackmapSpecial.cpp:
319         (JSC::B3::StackmapSpecial::forEachArgImpl):
320         (JSC::B3::StackmapSpecial::isValidImpl):
321         * b3/B3StackmapValue.cpp:
322         (JSC::B3::StackmapValue::append):
323         (JSC::B3::StackmapValue::StackmapValue):
324         * b3/B3StackmapValue.h:
325         * b3/B3SwitchValue.cpp:
326         (JSC::B3::SwitchValue::SwitchValue):
327         (JSC::B3::SwitchValue::cloneImpl const): Deleted.
328         * b3/B3SwitchValue.h:
329         (JSC::B3::SwitchValue::opcodeFromConstructor):
330         * b3/B3UpsilonValue.cpp:
331         (JSC::B3::UpsilonValue::cloneImpl const): Deleted.
332         * b3/B3UpsilonValue.h:
333         * b3/B3Value.cpp:
334         (JSC::B3::DeepValueDump::dump const):
335         (JSC::B3::Value::~Value):
336         (JSC::B3::Value::replaceWithIdentity):
337         (JSC::B3::Value::replaceWithNopIgnoringType):
338         (JSC::B3::Value::replaceWithPhi):
339         (JSC::B3::Value::replaceWithJump):
340         (JSC::B3::Value::replaceWithOops):
341         (JSC::B3::Value::replaceWith):
342         (JSC::B3::Value::invertedCompare const):
343         (JSC::B3::Value::returnsBool const):
344         (JSC::B3::Value::cloneImpl const): Deleted.
345         * b3/B3Value.h:
346         (JSC::B3::DeepValueDump::dump const): Deleted.
347         * b3/B3ValueInlines.h:
348         (JSC::B3::Value::adjacencyListOffset const):
349         (JSC::B3::Value::cloneImpl const):
350         * b3/B3VariableValue.cpp:
351         (JSC::B3::VariableValue::VariableValue):
352         (JSC::B3::VariableValue::cloneImpl const): Deleted.
353         * b3/B3VariableValue.h:
354         * b3/B3WasmAddressValue.cpp:
355         (JSC::B3::WasmAddressValue::WasmAddressValue):
356         (JSC::B3::WasmAddressValue::cloneImpl const): Deleted.
357         * b3/B3WasmAddressValue.h:
358         * b3/B3WasmBoundsCheckValue.cpp:
359         (JSC::B3::WasmBoundsCheckValue::WasmBoundsCheckValue):
360         (JSC::B3::WasmBoundsCheckValue::cloneImpl const): Deleted.
361         * b3/B3WasmBoundsCheckValue.h:
362         (JSC::B3::WasmBoundsCheckValue::accepts):
363         (JSC::B3::WasmBoundsCheckValue::opcodeFromConstructor):
364         * b3/testb3.cpp:
365         (JSC::B3::testCallFunctionWithHellaArguments):
366         (JSC::B3::testCallFunctionWithHellaArguments2):
367         (JSC::B3::testCallFunctionWithHellaArguments3):
368         (JSC::B3::testCallFunctionWithHellaDoubleArguments):
369         (JSC::B3::testCallFunctionWithHellaFloatArguments):
370         * ftl/FTLOutput.h:
371         (JSC::FTL::Output::call):
372
373 2019-04-15  Tadeu Zagallo  <tzagallo@apple.com>
374
375         Bytecode cache should not encode the SourceProvider for UnlinkedFunctionExecutable's classSource
376         https://bugs.webkit.org/show_bug.cgi?id=196878
377
378         Reviewed by Saam Barati.
379
380         Every time we encode an (Unlinked)SourceCode, we encode its SourceProvider,
381         including the full source if it's a StringSourceProvider. This wasn't an issue,
382         since the SourceCode contains a RefPtr to the SourceProvider, and the Encoder
383         would avoid encoding the provider multiple times. With the addition of the
384         incremental cache, each UnlinkedFunctionCodeBlock is encoded in isolation, which
385         means we can no longer deduplicate it and the full program text was being encoded
386         multiple times in the cache.
387         As a work around, this patch adds a custom cached type for encoding the SourceCode
388         without its provider, and later injects the SourceProvider through the Decoder.
389
390         * parser/SourceCode.h:
391         * parser/UnlinkedSourceCode.h:
392         (JSC::UnlinkedSourceCode::provider const):
393         * runtime/CachedTypes.cpp:
394         (JSC::Decoder::Decoder):
395         (JSC::Decoder::create):
396         (JSC::Decoder::provider const):
397         (JSC::CachedSourceCodeWithoutProvider::encode):
398         (JSC::CachedSourceCodeWithoutProvider::decode const):
399         (JSC::decodeCodeBlockImpl):
400         * runtime/CachedTypes.h:
401
402 2019-04-15  Robin Morisset  <rmorisset@apple.com>
403
404         MarkedSpace.cpp is not in the Xcode workspace
405         https://bugs.webkit.org/show_bug.cgi?id=196928
406
407         Reviewed by Saam Barati.
408
409         * JavaScriptCore.xcodeproj/project.pbxproj:
410
411 2019-04-15  Tadeu Zagallo  <tzagallo@apple.com>
412
413         Incremental bytecode cache should not append function updates when loaded from memory
414         https://bugs.webkit.org/show_bug.cgi?id=196865
415
416         Reviewed by Filip Pizlo.
417
418         Function updates hold the assumption that a function can only be executed/cached
419         after its containing code block has already been cached. This assumptions does
420         not hold if the UnlinkedCodeBlock is loaded from memory by the CodeCache, since
421         we might have two independent SourceProviders executing different paths of the
422         code and causing the same UnlinkedCodeBlock to be modified in memory.
423         Use a RefPtr instead of Ref for m_cachedBytecode in ShellSourceProvider to distinguish
424         between a new, empty cache and a cache that was not loaded and therefore cannot be updated.
425
426         * jsc.cpp:
427         (ShellSourceProvider::ShellSourceProvider):
428
429 2019-04-15  Saam barati  <sbarati@apple.com>
430
431         mergeOSREntryValue is wrong when the incoming value does not match up with the flush format
432         https://bugs.webkit.org/show_bug.cgi?id=196918
433
434         Reviewed by Yusuke Suzuki.
435
436         r244238 lead to some debug failures because we were calling checkConsistency()
437         before doing fixTypeForRepresentation when merging in must handle values in
438         CFA. This patch fixes that.
439         
440         However, as I was reading over mergeOSREntryValue, I realized it was wrong. It
441         was possible it could merge in a value/type outside of the variable's flushed type.
442         Once the flush format types are locked in, we can't introduce a type out of
443         that range. This probably never lead to any crashes as our profiling injection
444         and speculation decision code is solid. However, what we were doing is clearly
445         wrong, and something a fuzzer could have found if we fuzzed the must handle
446         values inside prediction injection. We should do that fuzzing:
447         https://bugs.webkit.org/show_bug.cgi?id=196924
448
449         * dfg/DFGAbstractValue.cpp:
450         (JSC::DFG::AbstractValue::mergeOSREntryValue):
451         * dfg/DFGAbstractValue.h:
452         * dfg/DFGCFAPhase.cpp:
453         (JSC::DFG::CFAPhase::injectOSR):
454
455 2019-04-15  Robin Morisset  <rmorisset@apple.com>
456
457         Several structures and enums in the Yarr interpreter can be shrunk
458         https://bugs.webkit.org/show_bug.cgi?id=196923
459
460         Reviewed by Saam Barati.
461
462         YarrOp: 88 -> 80
463         RegularExpression: 40 -> 32
464         ByteTerm: 56 -> 48
465         PatternTerm: 56 -> 48
466
467         * yarr/RegularExpression.cpp:
468         * yarr/YarrInterpreter.h:
469         * yarr/YarrJIT.cpp:
470         (JSC::Yarr::YarrGenerator::YarrOp::YarrOp):
471         * yarr/YarrParser.h:
472         * yarr/YarrPattern.h:
473
474 2019-04-15  Devin Rousso  <drousso@apple.com>
475
476         Web Inspector: REGRESSION(r244172): crash when trying to add extra domain while inspecting JSContext
477         https://bugs.webkit.org/show_bug.cgi?id=196925
478         <rdar://problem/49873994>
479
480         Reviewed by Joseph Pecoraro.
481
482         Move the logic for creating the `InspectorAgent` and `InspectorDebuggerAgent` into separate
483         functions so that callers can be guaranteed to have a valid instance of the agent.
484
485         * inspector/JSGlobalObjectInspectorController.h:
486         * inspector/JSGlobalObjectInspectorController.cpp:
487         (Inspector::JSGlobalObjectInspectorController::connectFrontend):
488         (Inspector::JSGlobalObjectInspectorController::frontendInitialized):
489         (Inspector::JSGlobalObjectInspectorController::appendExtraAgent):
490         (Inspector::JSGlobalObjectInspectorController::ensureInspectorAgent): Added.
491         (Inspector::JSGlobalObjectInspectorController::ensureDebuggerAgent): Added.
492         (Inspector::JSGlobalObjectInspectorController::createLazyAgents):
493
494 2019-04-14  Don Olmstead  <don.olmstead@sony.com>
495
496         [CMake] JavaScriptCore derived sources should only be referenced inside JavaScriptCore
497         https://bugs.webkit.org/show_bug.cgi?id=196742
498
499         Reviewed by Konstantin Tokarev.
500
501         Migrate to using JavaScriptCore_DERIVED_SOURCES_DIR instead of DERIVED_SOURCES_JAVASCRIPTCORE_DIR
502         to support moving the JavaScriptCore derived sources outside of a shared directory.
503
504         Also use JavaScriptCore_DERIVED_SOURCES_DIR instead of DERIVED_SOUCES_DIR.
505
506         * CMakeLists.txt:
507
508 2019-04-13  Tadeu Zagallo  <tzagallo@apple.com>
509
510         CodeCache should check that the UnlinkedCodeBlock was successfully created before caching it
511         https://bugs.webkit.org/show_bug.cgi?id=196880
512
513         Reviewed by Yusuke Suzuki.
514
515         CodeCache should not tell the SourceProvider to cache the bytecode if it failed
516         to create the UnlinkedCodeBlock.
517
518         * runtime/CodeCache.cpp:
519         (JSC::CodeCache::getUnlinkedGlobalCodeBlock):
520
521 2019-04-12  Saam barati  <sbarati@apple.com>
522
523         r244079 logically broke shouldSpeculateInt52
524         https://bugs.webkit.org/show_bug.cgi?id=196884
525
526         Reviewed by Yusuke Suzuki.
527
528         In r244079, I changed shouldSpeculateInt52 to only return true
529         when the prediction is isAnyInt52Speculation(). However, it was
530         wrong to not to include SpecInt32 in this for two reasons:
531
532         1. We diligently write code that first checks if we should speculate Int32.
533         For example:
534         if (shouldSpeculateInt32()) ... 
535         else if (shouldSpeculateInt52()) ...
536
537         It would be wrong not to fall back to Int52 if we're dealing with the union of
538         Int32 and Int52.
539
540         It would be a performance mistake to not include Int32 here because
541         data flow can easily tell us that we have variables that are the union
542         of Int32 and Int52 values. It's better to speculate Int52 than Double
543         in that situation.
544
545         2. We also write code where we ask if the inputs can be Int52, e.g, if
546         we know via profiling that an Add overflows, we may not emit an Int32 add.
547         However, we only emit such an add if both inputs can be Int52, and Int32
548         can trivially become Int52.
549
550        This patch recovers the 0.5-1% regression r244079 caused on JetStream 2.
551
552         * bytecode/SpeculatedType.h:
553         (JSC::isInt32SpeculationForArithmetic):
554         (JSC::isInt32OrBooleanSpeculationForArithmetic):
555         (JSC::isInt32OrInt52Speculation):
556         * dfg/DFGFixupPhase.cpp:
557         (JSC::DFG::FixupPhase::observeUseKindOnNode):
558         * dfg/DFGNode.h:
559         (JSC::DFG::Node::shouldSpeculateInt52):
560         * dfg/DFGPredictionPropagationPhase.cpp:
561         * dfg/DFGVariableAccessData.cpp:
562         (JSC::DFG::VariableAccessData::couldRepresentInt52Impl):
563
564 2019-04-12  Saam barati  <sbarati@apple.com>
565
566         Unreviewed. Build fix after r244233.
567
568         * assembler/CPU.cpp:
569
570 2019-04-12  Saam barati  <sbarati@apple.com>
571
572         Sometimes we need to user fewer CPUs in our threading calculations
573         https://bugs.webkit.org/show_bug.cgi?id=196794
574         <rdar://problem/49389497>
575
576         Reviewed by Yusuke Suzuki.
577
578         * JavaScriptCore.xcodeproj/project.pbxproj:
579         * Sources.txt:
580         * assembler/CPU.cpp: Added.
581         (JSC::isKernTCSMAvailable):
582         (JSC::enableKernTCSM):
583         (JSC::kernTCSMAwareNumberOfProcessorCores):
584         * assembler/CPU.h:
585         (JSC::isKernTCSMAvailable):
586         (JSC::enableKernTCSM):
587         (JSC::kernTCSMAwareNumberOfProcessorCores):
588         * heap/MachineStackMarker.h:
589         (JSC::MachineThreads::addCurrentThread):
590         * runtime/JSLock.cpp:
591         (JSC::JSLock::didAcquireLock):
592         * runtime/Options.cpp:
593         (JSC::computeNumberOfWorkerThreads):
594         (JSC::computePriorityDeltaOfWorkerThreads):
595         * wasm/WasmWorklist.cpp:
596         (JSC::Wasm::Worklist::Worklist):
597
598 2019-04-12  Robin Morisset  <rmorisset@apple.com>
599
600         Use padding at end of ArrayBuffer
601         https://bugs.webkit.org/show_bug.cgi?id=196823
602
603         Reviewed by Filip Pizlo.
604
605         * runtime/ArrayBuffer.h:
606
607 2019-04-11  Yusuke Suzuki  <ysuzuki@apple.com>
608
609         [JSC] op_has_indexed_property should not assume subscript part is Uint32
610         https://bugs.webkit.org/show_bug.cgi?id=196850
611
612         Reviewed by Saam Barati.
613
614         op_has_indexed_property assumed that subscript part is always Uint32. However, this is just a load from non-constant RegisterID,
615         DFG can store it in double format and can perform OSR exit. op_has_indexed_property should not assume that.
616         In this patch, instead, we check it with isAnyInt and get uint32_t from AnyInt.
617
618         * jit/JITOpcodes.cpp:
619         (JSC::JIT::emit_op_has_indexed_property):
620         * jit/JITOpcodes32_64.cpp:
621         (JSC::JIT::emit_op_has_indexed_property):
622         * jit/JITOperations.cpp:
623         * runtime/CommonSlowPaths.cpp:
624         (JSC::SLOW_PATH_DECL):
625
626 2019-04-11  Saam barati  <sbarati@apple.com>
627
628         Remove invalid assertion in operationInstanceOfCustom
629         https://bugs.webkit.org/show_bug.cgi?id=196842
630         <rdar://problem/49725493>
631
632         Reviewed by Michael Saboff.
633
634         In the generated JIT code, we go to the slow path when the incoming function
635         isn't the Node's CodeOrigin's functionProtoHasInstanceSymbolFunction. However,
636         in the JIT operation, we were asserting against exec->lexicalGlobalObject()'s
637         functionProtoHasInstanceSymbolFunction. That assertion might be wrong when
638         inlining across global objects as exec->lexicalGlobalObject() uses the machine
639         frame for procuring the global object. There is no harm when this assertion fails
640         as we just execute the slow path. This patch removes the assertion. (However, this
641         does shed light on the deficiency in our exec->lexicalGlobalObject() function with
642         respect to inlining. However, this isn't new -- we've known about this for a while.)
643
644         * jit/JITOperations.cpp:
645
646 2019-04-11  Michael Saboff  <msaboff@apple.com>
647
648         Improve the Inline Cache Stats code
649         https://bugs.webkit.org/show_bug.cgi?id=196836
650
651         Reviewed by Saam Barati.
652
653         Needed to handle the case where the Identifier could be null, for example with InstanceOfAddAccessCase
654         and InstanceOfReplaceWithJump.
655
656         Added the ability to log the location of a GetBy and PutBy property as either on self or up the
657         protocol chain.
658
659         * jit/ICStats.cpp:
660         (JSC::ICEvent::operator< const):
661         (JSC::ICEvent::dump const):
662         * jit/ICStats.h:
663         (JSC::ICEvent::ICEvent):
664         (JSC::ICEvent::hash const):
665         * jit/JITOperations.cpp:
666         * jit/Repatch.cpp:
667         (JSC::tryCacheGetByID):
668         (JSC::tryCachePutByID):
669         (JSC::tryCacheInByID):
670
671 2019-04-11  Devin Rousso  <drousso@apple.com>
672
673         Web Inspector: Timelines: can't reliably stop/start a recording
674         https://bugs.webkit.org/show_bug.cgi?id=196778
675         <rdar://problem/47606798>
676
677         Reviewed by Timothy Hatcher.
678
679         * inspector/protocol/ScriptProfiler.json:
680         * inspector/protocol/Timeline.json:
681         It is possible to determine when programmatic capturing starts/stops in the frontend based
682         on the state when the backend causes the state to change, such as if the state is "inactive"
683         when the frontend is told that the backend has started capturing.
684
685         * inspector/protocol/CPUProfiler.json:
686         * inspector/protocol/Memory.json:
687         Send an end timestamp to match other instruments.
688
689         * inspector/JSGlobalObjectConsoleClient.cpp:
690         (Inspector::JSGlobalObjectConsoleClient::startConsoleProfile):
691         (Inspector::JSGlobalObjectConsoleClient::stopConsoleProfile):
692
693         * inspector/agents/InspectorScriptProfilerAgent.h:
694         * inspector/agents/InspectorScriptProfilerAgent.cpp:
695         (Inspector::InspectorScriptProfilerAgent::trackingComplete):
696         (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStarted): Deleted.
697         (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStopped): Deleted.
698
699 2019-04-11  Saam barati  <sbarati@apple.com>
700
701         Rename SetArgument to SetArgumentDefinitely
702         https://bugs.webkit.org/show_bug.cgi?id=196828
703
704         Reviewed by Yusuke Suzuki.
705
706         This is in preparation for https://bugs.webkit.org/show_bug.cgi?id=196712
707         where we will introduce a node named SetArgumentMaybe. Doing this refactoring
708         first will make reviewing that other patch easier.
709
710         * dfg/DFGAbstractInterpreterInlines.h:
711         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
712         * dfg/DFGByteCodeParser.cpp:
713         (JSC::DFG::ByteCodeParser::handleVarargsInlining):
714         (JSC::DFG::ByteCodeParser::parseBlock):
715         * dfg/DFGCPSRethreadingPhase.cpp:
716         (JSC::DFG::CPSRethreadingPhase::freeUnnecessaryNodes):
717         (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor):
718         (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor):
719         (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
720         (JSC::DFG::CPSRethreadingPhase::specialCaseArguments):
721         (JSC::DFG::CPSRethreadingPhase::propagatePhis):
722         (JSC::DFG::CPSRethreadingPhase::computeIsFlushed):
723         * dfg/DFGClobberize.h:
724         (JSC::DFG::clobberize):
725         * dfg/DFGCommon.h:
726         * dfg/DFGDoesGC.cpp:
727         (JSC::DFG::doesGC):
728         * dfg/DFGFixupPhase.cpp:
729         (JSC::DFG::FixupPhase::fixupNode):
730         * dfg/DFGGraph.cpp:
731         (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
732         * dfg/DFGGraph.h:
733         * dfg/DFGInPlaceAbstractState.cpp:
734         (JSC::DFG::InPlaceAbstractState::initialize):
735         (JSC::DFG::InPlaceAbstractState::endBasicBlock):
736         * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
737         (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlockForTryCatch):
738         * dfg/DFGMaximalFlushInsertionPhase.cpp:
739         (JSC::DFG::MaximalFlushInsertionPhase::treatRegularBlock):
740         (JSC::DFG::MaximalFlushInsertionPhase::treatRootBlock):
741         * dfg/DFGMayExit.cpp:
742         * dfg/DFGNode.cpp:
743         (JSC::DFG::Node::hasVariableAccessData):
744         * dfg/DFGNode.h:
745         (JSC::DFG::Node::convertPhantomToPhantomLocal):
746         * dfg/DFGNodeType.h:
747         * dfg/DFGOSREntrypointCreationPhase.cpp:
748         (JSC::DFG::OSREntrypointCreationPhase::run):
749         * dfg/DFGPhantomInsertionPhase.cpp:
750         * dfg/DFGPredictionPropagationPhase.cpp:
751         * dfg/DFGSSAConversionPhase.cpp:
752         (JSC::DFG::SSAConversionPhase::run):
753         * dfg/DFGSafeToExecute.h:
754         (JSC::DFG::safeToExecute):
755         * dfg/DFGSpeculativeJIT.cpp:
756         (JSC::DFG::SpeculativeJIT::checkArgumentTypes):
757         * dfg/DFGSpeculativeJIT32_64.cpp:
758         (JSC::DFG::SpeculativeJIT::compile):
759         * dfg/DFGSpeculativeJIT64.cpp:
760         (JSC::DFG::SpeculativeJIT::compile):
761         * dfg/DFGTypeCheckHoistingPhase.cpp:
762         (JSC::DFG::TypeCheckHoistingPhase::run):
763         * dfg/DFGValidate.cpp:
764         * ftl/FTLCapabilities.cpp:
765         (JSC::FTL::canCompile):
766
767 2019-04-11  Truitt Savell  <tsavell@apple.com>
768
769         Unreviewed, rolling out r244158.
770
771         Casued 8 inspector/timeline/ test failures.
772
773         Reverted changeset:
774
775         "Web Inspector: Timelines: can't reliably stop/start a
776         recording"
777         https://bugs.webkit.org/show_bug.cgi?id=196778
778         https://trac.webkit.org/changeset/244158
779
780 2019-04-10  Saam Barati  <sbarati@apple.com>
781
782         AbstractValue::validateOSREntryValue is wrong for Int52 constants
783         https://bugs.webkit.org/show_bug.cgi?id=196801
784         <rdar://problem/49771122>
785
786         Reviewed by Yusuke Suzuki.
787
788         validateOSREntryValue should not care about the format of the incoming
789         value for Int52s. This patch normalizes the format of m_value and
790         the incoming value when comparing them.
791
792         * dfg/DFGAbstractValue.h:
793         (JSC::DFG::AbstractValue::validateOSREntryValue const):
794
795 2019-04-10  Saam Barati  <sbarati@apple.com>
796
797         ArithSub over Int52 has shouldCheckOverflow as always true
798         https://bugs.webkit.org/show_bug.cgi?id=196796
799
800         Reviewed by Yusuke Suzuki.
801
802         AI was checking for ArithSub over Int52 if !shouldCheckOverflow. However,
803         shouldCheckOverflow is always true, so !shouldCheckOverflow is always
804         false. We shouldn't check something we assert against.
805
806         * dfg/DFGAbstractInterpreterInlines.h:
807         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
808
809 2019-04-10  Basuke Suzuki  <basuke.suzuki@sony.com>
810
811         [PlayStation] Specify byte order clearly on Remote Inspector Protocol
812         https://bugs.webkit.org/show_bug.cgi?id=196790
813
814         Reviewed by Ross Kirsling.
815
816         Original implementation lacks byte order specification. Network byte order is the
817         good candidate if there's no strong reason to choose other.
818         Currently no client exists for PlayStation remote inspector protocol, so we can
819         change the byte order without care.
820
821         * inspector/remote/playstation/RemoteInspectorMessageParserPlayStation.cpp:
822         (Inspector::MessageParser::createMessage):
823         (Inspector::MessageParser::parse):
824
825 2019-04-10  Devin Rousso  <drousso@apple.com>
826
827        Web Inspector: Inspector: lazily create the agent
828        https://bugs.webkit.org/show_bug.cgi?id=195971
829        <rdar://problem/49039645>
830
831        Reviewed by Joseph Pecoraro.
832
833        * inspector/JSGlobalObjectInspectorController.cpp:
834        (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
835        (Inspector::JSGlobalObjectInspectorController::connectFrontend):
836        (Inspector::JSGlobalObjectInspectorController::appendExtraAgent):
837        (Inspector::JSGlobalObjectInspectorController::createLazyAgents):
838
839        * inspector/agents/InspectorAgent.h:
840        * inspector/agents/InspectorAgent.cpp:
841
842 2019-04-10  Saam Barati  <sbarati@apple.com>
843
844         Work around an arm64_32 LLVM miscompile bug
845         https://bugs.webkit.org/show_bug.cgi?id=196788
846
847         Reviewed by Yusuke Suzuki.
848
849         * runtime/CachedTypes.cpp:
850
851 2019-04-10  Devin Rousso  <drousso@apple.com>
852
853         Web Inspector: Timelines: can't reliably stop/start a recording
854         https://bugs.webkit.org/show_bug.cgi?id=196778
855         <rdar://problem/47606798>
856
857         Reviewed by Timothy Hatcher.
858
859         * inspector/protocol/ScriptProfiler.json:
860         * inspector/protocol/Timeline.json:
861         It is possible to determine when programmatic capturing starts/stops in the frontend based
862         on the state when the backend causes the state to change, such as if the state is "inactive"
863         when the frontend is told that the backend has started capturing.
864
865         * inspector/protocol/CPUProfiler.json:
866         * inspector/protocol/Memory.json:
867         Send an end timestamp to match other instruments.
868
869         * inspector/JSGlobalObjectConsoleClient.cpp:
870         (Inspector::JSGlobalObjectConsoleClient::startConsoleProfile):
871         (Inspector::JSGlobalObjectConsoleClient::stopConsoleProfile):
872
873         * inspector/agents/InspectorScriptProfilerAgent.h:
874         * inspector/agents/InspectorScriptProfilerAgent.cpp:
875         (Inspector::InspectorScriptProfilerAgent::trackingComplete):
876         (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStarted): Deleted.
877         (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStopped): Deleted.
878
879 2019-04-10  Tadeu Zagallo  <tzagallo@apple.com>
880
881         Unreviewed, fix watch build after r244143
882         https://bugs.webkit.org/show_bug.cgi?id=195000
883
884         The result of `lseek` should be `off_t` rather than `int`.
885
886         * jsc.cpp:
887
888 2019-04-10  Tadeu Zagallo  <tzagallo@apple.com>
889
890         Add support for incremental bytecode cache updates
891         https://bugs.webkit.org/show_bug.cgi?id=195000
892
893         Reviewed by Filip Pizlo.
894
895         Add support for incremental updates to the bytecode cache. The cache
896         is constructed as follows:
897         - When the cache is empty, the initial payload can be added to the BytecodeCache
898         by calling BytecodeCache::addGlobalUpdate. This represents the encoded
899         top-level UnlinkedCodeBlock.
900         - Afterwards, updates can be added by calling BytecodeCache::addFunctionUpdate.
901         The update is applied by appending the encoded UnlinkedFunctionCodeBlock
902         to the existing cache and updating the CachedFunctionExecutableMetadata
903         and the offset of the new CachedFunctionCodeBlock in the owner CachedFunctionExecutable.
904
905         * API/JSScript.mm:
906         (-[JSScript readCache]):
907         (-[JSScript isUsingBytecodeCache]):
908         (-[JSScript init]):
909         (-[JSScript cachedBytecode]):
910         (-[JSScript writeCache:]):
911         * API/JSScriptInternal.h:
912         * API/JSScriptSourceProvider.h:
913         * API/JSScriptSourceProvider.mm:
914         (JSScriptSourceProvider::cachedBytecode const):
915         * CMakeLists.txt:
916         * JavaScriptCore.xcodeproj/project.pbxproj:
917         * Sources.txt:
918         * bytecode/UnlinkedFunctionExecutable.cpp:
919         (JSC::generateUnlinkedFunctionCodeBlock):
920         * jsc.cpp:
921         (ShellSourceProvider::~ShellSourceProvider):
922         (ShellSourceProvider::cachePath const):
923         (ShellSourceProvider::loadBytecode const):
924         (ShellSourceProvider::ShellSourceProvider):
925         (ShellSourceProvider::cacheEnabled):
926         * parser/SourceProvider.h:
927         (JSC::SourceProvider::cachedBytecode const):
928         (JSC::SourceProvider::updateCache const):
929         (JSC::SourceProvider::commitCachedBytecode const):
930         * runtime/CachePayload.cpp: Copied from Source/JavaScriptCore/API/JSScriptInternal.h.
931         (JSC::CachePayload::makeMappedPayload):
932         (JSC::CachePayload::makeMallocPayload):
933         (JSC::CachePayload::makeEmptyPayload):
934         (JSC::CachePayload::CachePayload):
935         (JSC::CachePayload::~CachePayload):
936         (JSC::CachePayload::operator=):
937         (JSC::CachePayload::freeData):
938         * runtime/CachePayload.h: Copied from Source/JavaScriptCore/API/JSScriptInternal.h.
939         (JSC::CachePayload::data const):
940         (JSC::CachePayload::size const):
941         (JSC::CachePayload::CachePayload):
942         * runtime/CacheUpdate.cpp: Copied from Source/JavaScriptCore/API/JSScriptInternal.h.
943         (JSC::CacheUpdate::CacheUpdate):
944         (JSC::CacheUpdate::operator=):
945         (JSC::CacheUpdate::isGlobal const):
946         (JSC::CacheUpdate::asGlobal const):
947         (JSC::CacheUpdate::asFunction const):
948         * runtime/CacheUpdate.h: Copied from Source/JavaScriptCore/API/JSScriptInternal.h.
949         * runtime/CachedBytecode.cpp: Added.
950         (JSC::CachedBytecode::addGlobalUpdate):
951         (JSC::CachedBytecode::addFunctionUpdate):
952         (JSC::CachedBytecode::copyLeafExecutables):
953         (JSC::CachedBytecode::commitUpdates const):
954         * runtime/CachedBytecode.h: Added.
955         (JSC::CachedBytecode::create):
956         (JSC::CachedBytecode::leafExecutables):
957         (JSC::CachedBytecode::data const):
958         (JSC::CachedBytecode::size const):
959         (JSC::CachedBytecode::hasUpdates const):
960         (JSC::CachedBytecode::sizeForUpdate const):
961         (JSC::CachedBytecode::CachedBytecode):
962         * runtime/CachedTypes.cpp:
963         (JSC::Encoder::addLeafExecutable):
964         (JSC::Encoder::release):
965         (JSC::Decoder::Decoder):
966         (JSC::Decoder::create):
967         (JSC::Decoder::size const):
968         (JSC::Decoder::offsetOf):
969         (JSC::Decoder::ptrForOffsetFromBase):
970         (JSC::Decoder::addLeafExecutable):
971         (JSC::VariableLengthObject::VariableLengthObject):
972         (JSC::VariableLengthObject::buffer const):
973         (JSC::CachedPtrOffsets::offsetOffset):
974         (JSC::CachedWriteBarrierOffsets::ptrOffset):
975         (JSC::CachedFunctionExecutable::features const):
976         (JSC::CachedFunctionExecutable::hasCapturedVariables const):
977         (JSC::CachedFunctionExecutableOffsets::codeBlockForCallOffset):
978         (JSC::CachedFunctionExecutableOffsets::codeBlockForConstructOffset):
979         (JSC::CachedFunctionExecutableOffsets::metadataOffset):
980         (JSC::CachedFunctionExecutable::encode):
981         (JSC::CachedFunctionExecutable::decode const):
982         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
983         (JSC::encodeCodeBlock):
984         (JSC::encodeFunctionCodeBlock):
985         (JSC::decodeCodeBlockImpl):
986         (JSC::isCachedBytecodeStillValid):
987         * runtime/CachedTypes.h:
988         (JSC::VariableLengthObjectBase::VariableLengthObjectBase):
989         (JSC::decodeCodeBlock):
990         * runtime/CodeCache.cpp:
991         (JSC::CodeCache::getUnlinkedGlobalCodeBlock):
992         (JSC::CodeCache::updateCache):
993         (JSC::CodeCache::write):
994         (JSC::writeCodeBlock):
995         (JSC::serializeBytecode):
996         * runtime/CodeCache.h:
997         (JSC::SourceCodeValue::SourceCodeValue):
998         (JSC::CodeCacheMap::findCacheAndUpdateAge):
999         (JSC::CodeCacheMap::fetchFromDiskImpl):
1000         * runtime/Completion.cpp:
1001         (JSC::generateProgramBytecode):
1002         (JSC::generateModuleBytecode):
1003         * runtime/Completion.h:
1004         * runtime/LeafExecutable.cpp: Copied from Source/JavaScriptCore/API/JSScriptSourceProvider.mm.
1005         (JSC::LeafExecutable::operator+ const):
1006         * runtime/LeafExecutable.h: Copied from Source/JavaScriptCore/API/JSScriptSourceProvider.mm.
1007         (JSC::LeafExecutable::LeafExecutable):
1008         (JSC::LeafExecutable::base const):
1009
1010 2019-04-10  Michael Catanzaro  <mcatanzaro@igalia.com>
1011
1012         Unreviewed, rolling out r243989.
1013
1014         Broke i686 builds
1015
1016         Reverted changeset:
1017
1018         "[CMake] Detect SSE2 at compile time"
1019         https://bugs.webkit.org/show_bug.cgi?id=196488
1020         https://trac.webkit.org/changeset/243989
1021
1022 2019-04-10  Robin Morisset  <rmorisset@apple.com>
1023
1024         We should clear m_needsOverflowCheck when hitting an exception in defineProperties in ObjectConstructor.cpp
1025         https://bugs.webkit.org/show_bug.cgi?id=196746
1026
1027         Reviewed by Yusuke Suzuki..
1028
1029         It should be safe as in that case we are not completing the operation, and so not going to have any buffer overflow.
1030
1031         * runtime/ObjectConstructor.cpp:
1032         (JSC::defineProperties):
1033
1034 2019-04-10  Antoine Quint  <graouts@apple.com>
1035
1036         Enable Pointer Events on watchOS
1037         https://bugs.webkit.org/show_bug.cgi?id=196771
1038         <rdar://problem/49040909>
1039
1040         Reviewed by Dean Jackson.
1041
1042         * Configurations/FeatureDefines.xcconfig:
1043
1044 2019-04-09  Keith Rollin  <krollin@apple.com>
1045
1046         Unreviewed build maintenance -- update .xcfilelists.
1047
1048         * DerivedSources-input.xcfilelist:
1049
1050 2019-04-09  Ross Kirsling  <ross.kirsling@sony.com>
1051
1052         JSC should build successfully even with -DENABLE_UNIFIED_BUILDS=OFF
1053         https://bugs.webkit.org/show_bug.cgi?id=193073
1054
1055         Reviewed by Keith Miller.
1056
1057         * bytecompiler/BytecodeGenerator.cpp:
1058         (JSC::BytecodeGenerator::emitEqualityOpImpl):
1059         (JSC::BytecodeGenerator::emitEqualityOp): Deleted.
1060         * bytecompiler/BytecodeGenerator.h:
1061         (JSC::BytecodeGenerator::emitEqualityOp):
1062         Factor out the logic that uses the template parameter and keep it in the header.
1063
1064         * jit/JITPropertyAccess.cpp:
1065         List off the template specializations needed by JITOperations.cpp.
1066         This is unfortunate but at least there are only two (x2) by definition?
1067         Trying to do away with this incurs a severe domino effect...
1068
1069         * API/JSValueRef.cpp:
1070         * b3/B3OptimizeAssociativeExpressionTrees.cpp:
1071         * b3/air/AirHandleCalleeSaves.cpp:
1072         * builtins/BuiltinNames.cpp:
1073         * bytecode/AccessCase.cpp:
1074         * bytecode/BytecodeIntrinsicRegistry.cpp:
1075         * bytecode/BytecodeIntrinsicRegistry.h:
1076         * bytecode/BytecodeRewriter.cpp:
1077         * bytecode/BytecodeUseDef.h:
1078         * bytecode/CodeBlock.cpp:
1079         * bytecode/InstanceOfAccessCase.cpp:
1080         * bytecode/MetadataTable.cpp:
1081         * bytecode/PolyProtoAccessChain.cpp:
1082         * bytecode/StructureSet.cpp:
1083         * bytecompiler/NodesCodegen.cpp:
1084         * dfg/DFGCFAPhase.cpp:
1085         * dfg/DFGPureValue.cpp:
1086         * heap/GCSegmentedArray.h:
1087         * heap/HeapInlines.h:
1088         * heap/IsoSubspace.cpp:
1089         * heap/LocalAllocator.cpp:
1090         * heap/LocalAllocator.h:
1091         * heap/LocalAllocatorInlines.h:
1092         * heap/MarkingConstraintSolver.cpp:
1093         * inspector/ScriptArguments.cpp:
1094         (Inspector::ScriptArguments::isEqual const):
1095         * inspector/ScriptCallStackFactory.cpp:
1096         * interpreter/CallFrame.h:
1097         * interpreter/Interpreter.cpp:
1098         * interpreter/StackVisitor.cpp:
1099         * llint/LLIntEntrypoint.cpp:
1100         * runtime/ArrayIteratorPrototype.cpp:
1101         * runtime/BigIntPrototype.cpp:
1102         * runtime/CachedTypes.cpp:
1103         * runtime/ErrorType.cpp:
1104         * runtime/IndexingType.cpp:
1105         * runtime/JSCellInlines.h:
1106         * runtime/JSImmutableButterfly.h:
1107         * runtime/Operations.h:
1108         * runtime/RegExpCachedResult.cpp:
1109         * runtime/RegExpConstructor.cpp:
1110         * runtime/RegExpGlobalData.cpp:
1111         * runtime/StackFrame.h:
1112         * wasm/WasmSignature.cpp:
1113         * wasm/js/JSToWasm.cpp:
1114         * wasm/js/JSToWasmICCallee.cpp:
1115         * wasm/js/WebAssemblyFunction.h:
1116         Fix includes / forward declarations (and a couple of nearby clang warnings).
1117
1118 2019-04-09  Don Olmstead  <don.olmstead@sony.com>
1119
1120         [CMake] Apple builds should use ICU_INCLUDE_DIRS
1121         https://bugs.webkit.org/show_bug.cgi?id=196720
1122
1123         Reviewed by Konstantin Tokarev.
1124
1125         * PlatformMac.cmake:
1126
1127 2019-04-09  Saam barati  <sbarati@apple.com>
1128
1129         Clean up Int52 code and some bugs in it
1130         https://bugs.webkit.org/show_bug.cgi?id=196639
1131         <rdar://problem/49515757>
1132
1133         Reviewed by Yusuke Suzuki.
1134
1135         This patch fixes bugs in our Int52 code. The primary change in this patch is
1136         adopting a segregated type lattice for Int52. Previously, for Int52 values,
1137         we represented them with SpecInt32Only and SpecInt52Only. For an Int52,
1138         SpecInt32Only meant that the value is in int32 range. And SpecInt52Only meant
1139         that the is outside of the int32 range.
1140         
1141         However, this got confusing because we reused SpecInt32Only both for JSValue
1142         representations and Int52 representations. This actually lead to some bugs.
1143         
1144         1. It's possible that roundtripping through Int52 representation would say
1145         it produces the wrong type. For example, consider this program and how we
1146         used to annotate types in AI:
1147         a: JSConstant(10.0) => m_type is SpecAnyIntAsDouble
1148         b: Int52Rep(@a) => m_type is SpecInt52Only
1149         c: ValueRep(@b) => m_type is SpecAnyIntAsDouble
1150         
1151         In AI, for the above program, we'd say that @c produces SpecAnyIntAsDouble.
1152         However, the execution semantics are such that it'd actually produce a boxed
1153         Int32. This patch fixes the bug where we'd say that Int52Rep over SpecAnyIntAsDouble
1154         would produce SpecInt52Only. This is clearly wrong, as SpecAnyIntAsDouble can
1155         mean an int value in either int32 or int52 range.
1156         
1157         2. AsbstractValue::validateTypeAcceptingBoxedInt52 was wrong in how it
1158         accepted Int52 values. It was wrong in two different ways:
1159         a: If the AbstractValue's type was SpecInt52Only, and the incoming value
1160         was a boxed double, but represented a value in int32 range, the incoming
1161         value would incorrectly validate as being acceptable. However, we should
1162         have rejected this value.
1163         b: If the AbstractValue's type was SpecInt32Only, and the incoming value
1164         was an Int32 boxed in a double, this would not validate, even though
1165         it should have validated.
1166         
1167         Solving 2 was easiest if we segregated out the Int52 type into its own
1168         lattice. This patch makes a new Int52 lattice, which is composed of
1169         SpecInt32AsInt52 and SpecNonInt32AsInt52.
1170         
1171         The conversion rules are now really simple.
1172         
1173         Int52 rep => JSValue rep
1174         SpecInt32AsInt52 => SpecInt32Only
1175         SpecNonInt32AsInt52 => SpecAnyIntAsDouble
1176         
1177         JSValue rep => Int52 rep
1178         SpecInt32Only => SpecInt32AsInt52
1179         SpecAnyIntAsDouble => SpecInt52Any
1180         
1181         With these rules, the program in (1) will now correctly report that @c
1182         returns SpecInt32Only | SpecAnyIntAsDouble.
1183
1184         * bytecode/SpeculatedType.cpp:
1185         (JSC::dumpSpeculation):
1186         (JSC::speculationToAbbreviatedString):
1187         (JSC::int52AwareSpeculationFromValue):
1188         (JSC::leastUpperBoundOfStrictlyEquivalentSpeculations):
1189         (JSC::speculationFromString):
1190         * bytecode/SpeculatedType.h:
1191         (JSC::isInt32SpeculationForArithmetic):
1192         (JSC::isInt32OrBooleanSpeculationForArithmetic):
1193         (JSC::isAnyInt52Speculation):
1194         (JSC::isIntAnyFormat):
1195         (JSC::isInt52Speculation): Deleted.
1196         (JSC::isAnyIntSpeculation): Deleted.
1197         * dfg/DFGAbstractInterpreterInlines.h:
1198         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1199         * dfg/DFGAbstractValue.cpp:
1200         (JSC::DFG::AbstractValue::fixTypeForRepresentation):
1201         (JSC::DFG::AbstractValue::checkConsistency const):
1202         * dfg/DFGAbstractValue.h:
1203         (JSC::DFG::AbstractValue::isInt52Any const):
1204         (JSC::DFG::AbstractValue::validateTypeAcceptingBoxedInt52 const):
1205         * dfg/DFGFixupPhase.cpp:
1206         (JSC::DFG::FixupPhase::fixupArithMul):
1207         (JSC::DFG::FixupPhase::fixupNode):
1208         (JSC::DFG::FixupPhase::fixupGetPrototypeOf):
1209         (JSC::DFG::FixupPhase::fixupToThis):
1210         (JSC::DFG::FixupPhase::fixupToStringOrCallStringConstructor):
1211         (JSC::DFG::FixupPhase::observeUseKindOnNode):
1212         (JSC::DFG::FixupPhase::fixIntConvertingEdge):
1213         (JSC::DFG::FixupPhase::attemptToMakeIntegerAdd):
1214         (JSC::DFG::FixupPhase::fixupCompareStrictEqAndSameValue):
1215         (JSC::DFG::FixupPhase::fixupChecksInBlock):
1216         * dfg/DFGGraph.h:
1217         (JSC::DFG::Graph::addShouldSpeculateInt52):
1218         (JSC::DFG::Graph::binaryArithShouldSpeculateInt52):
1219         (JSC::DFG::Graph::unaryArithShouldSpeculateInt52):
1220         (JSC::DFG::Graph::addShouldSpeculateAnyInt): Deleted.
1221         (JSC::DFG::Graph::binaryArithShouldSpeculateAnyInt): Deleted.
1222         (JSC::DFG::Graph::unaryArithShouldSpeculateAnyInt): Deleted.
1223         * dfg/DFGNode.h:
1224         (JSC::DFG::Node::shouldSpeculateInt52):
1225         (JSC::DFG::Node::shouldSpeculateAnyInt): Deleted.
1226         * dfg/DFGPredictionPropagationPhase.cpp:
1227         * dfg/DFGSpeculativeJIT.cpp:
1228         (JSC::DFG::SpeculativeJIT::setIntTypedArrayLoadResult):
1229         (JSC::DFG::SpeculativeJIT::compileArithAdd):
1230         (JSC::DFG::SpeculativeJIT::compileArithSub):
1231         (JSC::DFG::SpeculativeJIT::compileArithNegate):
1232         * dfg/DFGSpeculativeJIT64.cpp:
1233         (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
1234         (JSC::DFG::SpeculativeJIT::fillSpeculateInt52):
1235         * dfg/DFGUseKind.h:
1236         (JSC::DFG::typeFilterFor):
1237         * dfg/DFGVariableAccessData.cpp:
1238         (JSC::DFG::VariableAccessData::makePredictionForDoubleFormat):
1239         (JSC::DFG::VariableAccessData::couldRepresentInt52Impl):
1240         * ftl/FTLLowerDFGToB3.cpp:
1241         (JSC::FTL::DFG::LowerDFGToB3::compileArithAddOrSub):
1242         (JSC::FTL::DFG::LowerDFGToB3::compileArithNegate):
1243         (JSC::FTL::DFG::LowerDFGToB3::setIntTypedArrayLoadResult):
1244
1245 2019-04-09  Tadeu Zagallo  <tzagallo@apple.com>
1246
1247         ASSERTION FAILED: !scope.exception() || !hasProperty in JSObject::get
1248         https://bugs.webkit.org/show_bug.cgi?id=196708
1249         <rdar://problem/49556803>
1250
1251         Reviewed by Yusuke Suzuki.
1252
1253         `operationPutToScope` needs to return early if an exception is thrown while
1254         checking if `hasProperty`.
1255
1256         * jit/JITOperations.cpp:
1257
1258 2019-04-08  Yusuke Suzuki  <ysuzuki@apple.com>
1259
1260         [JSC] DFG should respect node's strict flag
1261         https://bugs.webkit.org/show_bug.cgi?id=196617
1262
1263         Reviewed by Saam Barati.
1264
1265         We accidentally use codeBlock->isStrictMode() directly in DFG and FTL. But this is wrong since this CodeBlock is the top level DFG/FTL CodeBlock,
1266         and this code does not respect the isStrictMode flag for the inlined CodeBlocks. In this patch, we start using isStrictModeFor(CodeOrigin) consistently
1267         in DFG and FTL to get the right isStrictMode flag for the DFG node.
1268         And we also split compilePutDynamicVar into compilePutDynamicVarStrict and compilePutDynamicVarNonStrict since (1) it is cleaner than accessing inlined
1269         callframe in the operation function, and (2) it is aligned to the other functions like operationPutByValDirectNonStrict etc.
1270         This bug is discovered by RandomizingFuzzerAgent by expanding the DFG coverage.
1271
1272         * dfg/DFGAbstractInterpreterInlines.h:
1273         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1274         * dfg/DFGConstantFoldingPhase.cpp:
1275         (JSC::DFG::ConstantFoldingPhase::foldConstants):
1276         * dfg/DFGFixupPhase.cpp:
1277         (JSC::DFG::FixupPhase::fixupToThis):
1278         * dfg/DFGOperations.cpp:
1279         * dfg/DFGOperations.h:
1280         * dfg/DFGPredictionPropagationPhase.cpp:
1281         * dfg/DFGSpeculativeJIT.cpp:
1282         (JSC::DFG::SpeculativeJIT::compileDoublePutByVal):
1283         (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
1284         (JSC::DFG::SpeculativeJIT::compilePutDynamicVar):
1285         (JSC::DFG::SpeculativeJIT::compileToThis):
1286         * dfg/DFGSpeculativeJIT32_64.cpp:
1287         (JSC::DFG::SpeculativeJIT::compileContiguousPutByVal):
1288         (JSC::DFG::SpeculativeJIT::compile):
1289         * dfg/DFGSpeculativeJIT64.cpp:
1290         (JSC::DFG::SpeculativeJIT::compile):
1291         * ftl/FTLLowerDFGToB3.cpp:
1292         (JSC::FTL::DFG::LowerDFGToB3::compilePutByVal):
1293         (JSC::FTL::DFG::LowerDFGToB3::compilePutDynamicVar):
1294
1295 2019-04-08  Don Olmstead  <don.olmstead@sony.com>
1296
1297         [CMake][WinCairo] Separate copied headers into different directories
1298         https://bugs.webkit.org/show_bug.cgi?id=196655
1299
1300         Reviewed by Michael Catanzaro.
1301
1302         * CMakeLists.txt:
1303         * shell/PlatformWin.cmake:
1304
1305 2019-04-08  Yusuke Suzuki  <ysuzuki@apple.com>
1306
1307         [JSC] isRope jump in StringSlice should not jump over register allocations
1308         https://bugs.webkit.org/show_bug.cgi?id=196716
1309
1310         Reviewed by Saam Barati.
1311
1312         Jumping over the register allocation code in DFG (like the following) is wrong.
1313
1314             auto jump = m_jit.branchXXX();
1315             {
1316                 GPRTemporary reg(this);
1317                 GPRReg regGPR = reg.gpr();
1318                 ...
1319             }
1320             jump.link(&m_jit);
1321
1322         When GPRTemporary::gpr allocates a new register, it can flush the previous register value into the stack and make the register usable.
1323         Jumping over this register allocation code skips the flushing code, and makes the DFG's stack and register content tracking inconsistent:
1324         DFG thinks that the content is flushed and stored in particular stack slot even while this flushing code is skipped.
1325         In this patch, we perform register allocations before jumping to the slow path based on `isRope` condition in StringSlice.
1326
1327         * dfg/DFGSpeculativeJIT.cpp:
1328         (JSC::DFG::SpeculativeJIT::compileStringSlice):
1329
1330 2019-04-08  Yusuke Suzuki  <ysuzuki@apple.com>
1331
1332         [JSC] to_index_string should not assume incoming value is Uint32
1333         https://bugs.webkit.org/show_bug.cgi?id=196713
1334
1335         Reviewed by Saam Barati.
1336
1337         The slow path of to_index_string assumes that incoming value is Uint32. But we should not have
1338         this assumption since DFG may decide we should have it double format. This patch removes this
1339         assumption, and instead, we should assume that incoming value is AnyInt and the range of this
1340         is within Uint32.
1341
1342         * runtime/CommonSlowPaths.cpp:
1343         (JSC::SLOW_PATH_DECL):
1344
1345 2019-04-08  Justin Fan  <justin_fan@apple.com>
1346
1347         [Web GPU] Fix Web GPU experimental feature on iOS
1348         https://bugs.webkit.org/show_bug.cgi?id=196632
1349
1350         Reviewed by Myles C. Maxfield.
1351
1352         Properly make Web GPU available on iOS 11+.
1353
1354         * Configurations/FeatureDefines.xcconfig:
1355         * Configurations/WebKitTargetConditionals.xcconfig:
1356
1357 2019-04-08  Ross Kirsling  <ross.kirsling@sony.com>
1358
1359         -f[no-]var-tracking-assignments is GCC-only
1360         https://bugs.webkit.org/show_bug.cgi?id=196699
1361
1362         Reviewed by Don Olmstead.
1363
1364         * CMakeLists.txt:
1365         Just remove the build flag altogether -- it supposedly doesn't solve the problem it was meant to
1366         and said problem evidently no longer occurs as of GCC 9.
1367
1368 2019-04-08  Saam Barati  <sbarati@apple.com>
1369
1370         WebAssembly.RuntimeError missing exception check
1371         https://bugs.webkit.org/show_bug.cgi?id=196700
1372         <rdar://problem/49693932>
1373
1374         Reviewed by Yusuke Suzuki.
1375
1376         * wasm/js/JSWebAssemblyRuntimeError.h:
1377         * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
1378         (JSC::constructJSWebAssemblyRuntimeError):
1379
1380 2019-04-08  Yusuke Suzuki  <ysuzuki@apple.com>
1381
1382         Unreviewed, rolling in r243948 with test fix
1383         https://bugs.webkit.org/show_bug.cgi?id=196486
1384
1385         * parser/ASTBuilder.h:
1386         (JSC::ASTBuilder::createString):
1387         * parser/Lexer.cpp:
1388         (JSC::Lexer<T>::parseMultilineComment):
1389         (JSC::Lexer<T>::lexWithoutClearingLineTerminator):
1390         (JSC::Lexer<T>::lex): Deleted.
1391         * parser/Lexer.h:
1392         (JSC::Lexer::hasLineTerminatorBeforeToken const):
1393         (JSC::Lexer::setHasLineTerminatorBeforeToken):
1394         (JSC::Lexer<T>::lex):
1395         (JSC::Lexer::prevTerminator const): Deleted.
1396         (JSC::Lexer::setTerminator): Deleted.
1397         * parser/Parser.cpp:
1398         (JSC::Parser<LexerType>::allowAutomaticSemicolon):
1399         (JSC::Parser<LexerType>::parseSingleFunction):
1400         (JSC::Parser<LexerType>::parseStatementListItem):
1401         (JSC::Parser<LexerType>::maybeParseAsyncFunctionDeclarationStatement):
1402         (JSC::Parser<LexerType>::parseFunctionInfo):
1403         (JSC::Parser<LexerType>::parseClass):
1404         (JSC::Parser<LexerType>::parseExportDeclaration):
1405         (JSC::Parser<LexerType>::parseAssignmentExpression):
1406         (JSC::Parser<LexerType>::parseYieldExpression):
1407         (JSC::Parser<LexerType>::parseProperty):
1408         (JSC::Parser<LexerType>::parsePrimaryExpression):
1409         (JSC::Parser<LexerType>::parseMemberExpression):
1410         * parser/Parser.h:
1411         (JSC::Parser::nextWithoutClearingLineTerminator):
1412         (JSC::Parser::lexCurrentTokenAgainUnderCurrentContext):
1413         (JSC::Parser::internalSaveLexerState):
1414         (JSC::Parser::restoreLexerState):
1415
1416 2019-04-08  Ryan Haddad  <ryanhaddad@apple.com>
1417
1418         Unreviewed, rolling out r243948.
1419
1420         Caused inspector/runtime/parse.html to fail
1421
1422         Reverted changeset:
1423
1424         "SIGSEGV in JSC::BytecodeGenerator::addStringConstant"
1425         https://bugs.webkit.org/show_bug.cgi?id=196486
1426         https://trac.webkit.org/changeset/243948
1427
1428 2019-04-08  Ryan Haddad  <ryanhaddad@apple.com>
1429
1430         Unreviewed, rolling out r243943.
1431
1432         Caused test262 failures.
1433
1434         Reverted changeset:
1435
1436         "[JSC] Filter DontEnum properties in
1437         ProxyObject::getOwnPropertyNames()"
1438         https://bugs.webkit.org/show_bug.cgi?id=176810
1439         https://trac.webkit.org/changeset/243943
1440
1441 2019-04-08  Claudio Saavedra  <csaavedra@igalia.com>
1442
1443         [JSC] Partially fix the build with unified builds disabled
1444         https://bugs.webkit.org/show_bug.cgi?id=196647
1445
1446         Reviewed by Konstantin Tokarev.
1447
1448         If you disable unified builds you find all kind of build
1449         errors. This partially tries to fix them but there's a lot
1450         more.
1451
1452         * API/JSBaseInternal.h:
1453         * b3/air/AirAllocateRegistersAndStackAndGenerateCode.cpp:
1454         * b3/air/AirHandleCalleeSaves.h:
1455         * bytecode/ExecutableToCodeBlockEdge.cpp:
1456         * bytecode/ExitFlag.h:
1457         * bytecode/ICStatusUtils.h:
1458         * bytecode/UnlinkedMetadataTable.h:
1459         * dfg/DFGPureValue.h:
1460         * heap/IsoAlignedMemoryAllocator.cpp:
1461         * heap/IsoAlignedMemoryAllocator.h:
1462
1463 2019-04-08  Guillaume Emont  <guijemont@igalia.com>
1464
1465         Enable DFG on MIPS
1466         https://bugs.webkit.org/show_bug.cgi?id=196689
1467
1468         Reviewed by Žan Doberšek.
1469
1470         Since the bytecode change, we enabled the baseline JIT on mips in
1471         r240432, but DFG is still missing. With this change, all tests are
1472         passing on a ci20 board.
1473
1474         * jit/RegisterSet.cpp:
1475         (JSC::RegisterSet::calleeSaveRegisters):
1476         Added s0, which is used in llint.
1477
1478 2019-04-08  Xan Lopez  <xan@igalia.com>
1479
1480         [CMake] Detect SSE2 at compile time
1481         https://bugs.webkit.org/show_bug.cgi?id=196488
1482
1483         Reviewed by Carlos Garcia Campos.
1484
1485         * assembler/MacroAssemblerX86Common.cpp: Remove unnecessary (and
1486         incorrect) static_assert.
1487
1488 2019-04-07  Michael Saboff  <msaboff@apple.com>
1489
1490         REGRESSION (r243642): Crash in reddit.com page
1491         https://bugs.webkit.org/show_bug.cgi?id=196684
1492
1493         Reviewed by Geoffrey Garen.
1494
1495         In r243642, the code that saves and restores the count for non-greedy character classes
1496         was inadvertently put inside an if statement.  This code should be generated for all
1497         non-greedy character classes.
1498
1499         * yarr/YarrJIT.cpp:
1500         (JSC::Yarr::YarrGenerator::generateCharacterClassNonGreedy):
1501         (JSC::Yarr::YarrGenerator::backtrackCharacterClassNonGreedy):
1502
1503 2019-04-07  Yusuke Suzuki  <ysuzuki@apple.com>
1504
1505         [JSC] CallLinkInfo should clear Callee or CodeBlock even if it is unlinked by jettison
1506         https://bugs.webkit.org/show_bug.cgi?id=196683
1507
1508         Reviewed by Saam Barati.
1509
1510         In r243626, we stop repatching CallLinkInfo when the CallLinkInfo is held by jettisoned CodeBlock.
1511         But we still need to clear the Callee or CodeBlock since they are now dead. Otherwise, CodeBlock's
1512         visitWeak eventually accesses this dead cells and crashes because the owner CodeBlock of CallLinkInfo
1513         can be still live.
1514
1515         We also move all repatching operations from CallLinkInfo.cpp to Repatch.cpp for consistency because the
1516         other repatching operations in CallLinkInfo are implemented in Repatch.cpp side.
1517
1518         * bytecode/CallLinkInfo.cpp:
1519         (JSC::CallLinkInfo::setCallee):
1520         (JSC::CallLinkInfo::clearCallee):
1521         * jit/Repatch.cpp:
1522         (JSC::linkFor):
1523         (JSC::revertCall):
1524
1525 2019-04-05  Yusuke Suzuki  <ysuzuki@apple.com>
1526
1527         [JSC] OSRExit recovery for SpeculativeAdd does not consier "A = A + A" pattern
1528         https://bugs.webkit.org/show_bug.cgi?id=196582
1529
1530         Reviewed by Saam Barati.
1531
1532         In DFG, our ArithAdd with overflow is executed speculatively, and we recover the value when overflow flag is set.
1533         The recovery is subtracting the operand from the destination to get the original two operands. Our recovery code
1534         handles A + B = A, A + B = B cases. But it misses A + A = A case (here, A and B are GPRReg). Our recovery code
1535         attempts to produce the original operand by performing A - A, and it always produces zero accidentally.
1536
1537         This patch adds the recovery code for A + A = A case. Because we know that this ArithAdd overflows, and operands were
1538         same values, we can calculate the original operand from the destination value by `((int32_t)value >> 1) ^ 0x80000000`.
1539
1540         We also found that FTL recovery code is dead. We remove them in this patch.
1541
1542         * dfg/DFGOSRExit.cpp:
1543         (JSC::DFG::OSRExit::executeOSRExit):
1544         (JSC::DFG::OSRExit::compileExit):
1545         * dfg/DFGOSRExit.h:
1546         (JSC::DFG::SpeculationRecovery::SpeculationRecovery):
1547         * dfg/DFGSpeculativeJIT.cpp:
1548         (JSC::DFG::SpeculativeJIT::compileArithAdd):
1549         * ftl/FTLExitValue.cpp:
1550         (JSC::FTL::ExitValue::dataFormat const):
1551         (JSC::FTL::ExitValue::dumpInContext const):
1552         * ftl/FTLExitValue.h:
1553         (JSC::FTL::ExitValue::isArgument const):
1554         (JSC::FTL::ExitValue::hasIndexInStackmapLocations const):
1555         (JSC::FTL::ExitValue::adjustStackmapLocationsIndexByOffset):
1556         (JSC::FTL::ExitValue::recovery): Deleted.
1557         (JSC::FTL::ExitValue::isRecovery const): Deleted.
1558         (JSC::FTL::ExitValue::leftRecoveryArgument const): Deleted.
1559         (JSC::FTL::ExitValue::rightRecoveryArgument const): Deleted.
1560         (JSC::FTL::ExitValue::recoveryFormat const): Deleted.
1561         (JSC::FTL::ExitValue::recoveryOpcode const): Deleted.
1562         * ftl/FTLLowerDFGToB3.cpp:
1563         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1564         (JSC::FTL::DFG::LowerDFGToB3::preparePatchpointForExceptions):
1565         (JSC::FTL::DFG::LowerDFGToB3::appendOSRExit):
1566         (JSC::FTL::DFG::LowerDFGToB3::exitValueForNode):
1567         (JSC::FTL::DFG::LowerDFGToB3::addAvailableRecovery): Deleted.
1568         * ftl/FTLOSRExitCompiler.cpp:
1569         (JSC::FTL::compileRecovery):
1570
1571 2019-04-05  Ryan Haddad  <ryanhaddad@apple.com>
1572
1573         Unreviewed, rolling out r243665.
1574
1575         Caused iOS JSC tests to exit with an exception.
1576
1577         Reverted changeset:
1578
1579         "Assertion failed in JSC::createError"
1580         https://bugs.webkit.org/show_bug.cgi?id=196305
1581         https://trac.webkit.org/changeset/243665
1582
1583 2019-04-05  Yusuke Suzuki  <ysuzuki@apple.com>
1584
1585         SIGSEGV in JSC::BytecodeGenerator::addStringConstant
1586         https://bugs.webkit.org/show_bug.cgi?id=196486
1587
1588         Reviewed by Saam Barati.
1589
1590         When parsing a FunctionExpression / FunctionDeclaration etc., we use SyntaxChecker for the body of the function because we do not have any interest on the nodes of the body at that time.
1591         The nodes will be parsed with the ASTBuilder when the function itself is parsed for code generation. This works well previously because all the function ends with "}" previously.
1592         SyntaxChecker lexes this "}" token, and parser restores the context back to ASTBuilder and continues parsing.
1593
1594         But now, we have ArrowFunctionExpression without braces `arrow => expr`. Let's consider the following code.
1595
1596                 arrow => expr
1597                 "string!"
1598
1599         We parse arrow function's body with SyntaxChecker. At that time, we lex "string!" token under the SyntaxChecker context. But this means that we may not build string content for this token
1600         since SyntaxChecker may not have interest on string content itself in certain case. After the parser is back to ASTBuilder, we parse "string!" as ExpressionStatement with string constant,
1601         generate StringNode with non-built identifier (nullptr), and we accidentally create StringNode with nullptr.
1602
1603         This patch fixes this problem. The root cause of this problem is that the last token lexed in the previous context is used. We add lexCurrentTokenAgainUnderCurrentContext which will re-lex
1604         the current token under the current context (may be ASTBuilder). This should be done only when the caller's context is different from SyntaxChecker, which avoids unnecessary lexing.
1605         We leverage existing SavePoint mechanism to implement lexCurrentTokenAgainUnderCurrentContext cleanly.
1606
1607         And we also fix the bug in the existing SavePoint mechanism, which is shown in the attached test script. When we save LexerState, we do not save line terminator status. This patch also introduces
1608         lexWithoutClearingLineTerminator, which lex the token without clearing line terminator status.
1609
1610         * parser/ASTBuilder.h:
1611         (JSC::ASTBuilder::createString):
1612         * parser/Lexer.cpp:
1613         (JSC::Lexer<T>::parseMultilineComment):
1614         (JSC::Lexer<T>::lexWithoutClearingLineTerminator): EOF token also should record offset information. This offset information is correctly handled in Lexer::setOffset too.
1615         (JSC::Lexer<T>::lex): Deleted.
1616         * parser/Lexer.h:
1617         (JSC::Lexer::hasLineTerminatorBeforeToken const):
1618         (JSC::Lexer::setHasLineTerminatorBeforeToken):
1619         (JSC::Lexer<T>::lex):
1620         (JSC::Lexer::prevTerminator const): Deleted.
1621         (JSC::Lexer::setTerminator): Deleted.
1622         * parser/Parser.cpp:
1623         (JSC::Parser<LexerType>::allowAutomaticSemicolon):
1624         (JSC::Parser<LexerType>::parseSingleFunction):
1625         (JSC::Parser<LexerType>::parseStatementListItem):
1626         (JSC::Parser<LexerType>::maybeParseAsyncFunctionDeclarationStatement):
1627         (JSC::Parser<LexerType>::parseFunctionInfo):
1628         (JSC::Parser<LexerType>::parseClass):
1629         (JSC::Parser<LexerType>::parseExportDeclaration):
1630         (JSC::Parser<LexerType>::parseAssignmentExpression):
1631         (JSC::Parser<LexerType>::parseYieldExpression):
1632         (JSC::Parser<LexerType>::parseProperty):
1633         (JSC::Parser<LexerType>::parsePrimaryExpression):
1634         (JSC::Parser<LexerType>::parseMemberExpression):
1635         * parser/Parser.h:
1636         (JSC::Parser::nextWithoutClearingLineTerminator):
1637         (JSC::Parser::lexCurrentTokenAgainUnderCurrentContext):
1638         (JSC::Parser::internalSaveLexerState):
1639         (JSC::Parser::restoreLexerState):
1640
1641 2019-04-05  Caitlin Potter  <caitp@igalia.com>
1642
1643         [JSC] Filter DontEnum properties in ProxyObject::getOwnPropertyNames()
1644         https://bugs.webkit.org/show_bug.cgi?id=176810
1645
1646         Reviewed by Saam Barati.
1647
1648         This adds conditional logic following the invariant checks, to perform
1649         filtering in common uses of getOwnPropertyNames.
1650
1651         While this would ideally only be done in JSPropertyNameEnumerator, adding
1652         the filtering to ProxyObject::performGetOwnPropertyNames maintains the
1653         invariant that the EnumerationMode is properly followed.
1654
1655         * runtime/PropertyNameArray.h:
1656         (JSC::PropertyNameArray::reset):
1657         * runtime/ProxyObject.cpp:
1658         (JSC::ProxyObject::performGetOwnPropertyNames):
1659
1660 2019-04-05  Commit Queue  <commit-queue@webkit.org>
1661
1662         Unreviewed, rolling out r243833.
1663         https://bugs.webkit.org/show_bug.cgi?id=196645
1664
1665         This change breaks build of WPE and GTK ports (Requested by
1666         annulen on #webkit).
1667
1668         Reverted changeset:
1669
1670         "[CMake][WTF] Mirror XCode header directories"
1671         https://bugs.webkit.org/show_bug.cgi?id=191662
1672         https://trac.webkit.org/changeset/243833
1673
1674 2019-04-05  Caitlin Potter  <caitp@igalia.com>
1675
1676         [JSC] throw if ownKeys Proxy trap result contains duplicate keys
1677         https://bugs.webkit.org/show_bug.cgi?id=185211
1678
1679         Reviewed by Saam Barati.
1680
1681         Implements the normative spec change in https://github.com/tc39/ecma262/pull/833
1682
1683         This involves tracking duplicate keys returned from the ownKeys trap in yet
1684         another HashTable, and may incur a minor performance penalty in some cases. This
1685         is not expected to significantly affect web performance.
1686
1687         * runtime/ProxyObject.cpp:
1688         (JSC::ProxyObject::performGetOwnPropertyNames):
1689
1690 2019-04-04  Yusuke Suzuki  <ysuzuki@apple.com>
1691
1692         [JSC] makeBoundFunction should not assume incoming "length" value is Int32 because it performs some calculation in bytecode
1693         https://bugs.webkit.org/show_bug.cgi?id=196631
1694
1695         Reviewed by Saam Barati.
1696
1697         makeBoundFunction assumes that "length" argument is always Int32. But this should not be done since this "length" value is calculated in builtin JS code.
1698         DFG may store this value in Double format so that we should not rely on that this value is Int32. This patch fixes makeBoundFunction function to perform
1699         toInt32 operation. We also insert a missing exception check for `JSString::value(ExecState*)` in makeBoundFunction.
1700
1701         * JavaScriptCore.xcodeproj/project.pbxproj:
1702         * Sources.txt:
1703         * interpreter/CallFrameInlines.h:
1704         * runtime/DoublePredictionFuzzerAgent.cpp: Copied from Source/JavaScriptCore/interpreter/CallFrameInlines.h.
1705         (JSC::DoublePredictionFuzzerAgent::DoublePredictionFuzzerAgent):
1706         (JSC::DoublePredictionFuzzerAgent::getPrediction):
1707         * runtime/DoublePredictionFuzzerAgent.h: Copied from Source/JavaScriptCore/interpreter/CallFrameInlines.h.
1708         * runtime/JSGlobalObject.cpp:
1709         (JSC::makeBoundFunction):
1710         * runtime/Options.h:
1711         * runtime/VM.cpp:
1712         (JSC::VM::VM):
1713
1714 2019-04-04  Robin Morisset  <rmorisset@apple.com>
1715
1716         B3ReduceStrength should know that Mul distributes over Add and Sub
1717         https://bugs.webkit.org/show_bug.cgi?id=196325
1718         <rdar://problem/49441650>
1719
1720         Reviewed by Saam Barati.
1721
1722         Fix some obviously wrong code that was due to an accidental copy-paste.
1723         It made the entire optimization dead code that never ran.
1724
1725         * b3/B3ReduceStrength.cpp:
1726
1727 2019-04-04  Saam Barati  <sbarati@apple.com>
1728
1729         Unreviewed, build fix for CLoop after r243886
1730
1731         * interpreter/Interpreter.cpp:
1732         (JSC::UnwindFunctor::copyCalleeSavesToEntryFrameCalleeSavesBuffer const):
1733         * interpreter/StackVisitor.cpp:
1734         (JSC::StackVisitor::Frame::calleeSaveRegistersForUnwinding):
1735         * interpreter/StackVisitor.h:
1736
1737 2019-04-04  Commit Queue  <commit-queue@webkit.org>
1738
1739         Unreviewed, rolling out r243898.
1740         https://bugs.webkit.org/show_bug.cgi?id=196624
1741
1742         `#if !ENABLE(C_LOOP) && NUMBER_OF_CALLEE_SAVES_REGISTERS > 0`
1743         does not work well (Requested by yusukesuzuki on #webkit).
1744
1745         Reverted changeset:
1746
1747         "Unreviewed, build fix for CLoop and Windows after r243886"
1748         https://bugs.webkit.org/show_bug.cgi?id=196387
1749         https://trac.webkit.org/changeset/243898
1750
1751 2019-04-04  Yusuke Suzuki  <ysuzuki@apple.com>
1752
1753         Unreviewed, build fix for CLoop and Windows after r243886
1754         https://bugs.webkit.org/show_bug.cgi?id=196387
1755
1756         RegisterAtOffsetList does not exist if ENABLE(ASSEMBLER) is false.
1757
1758         * interpreter/StackVisitor.cpp:
1759         (JSC::StackVisitor::Frame::calleeSaveRegistersForUnwinding):
1760         * interpreter/StackVisitor.h:
1761
1762 2019-04-04  Saam barati  <sbarati@apple.com>
1763
1764         Teach Call ICs how to call Wasm
1765         https://bugs.webkit.org/show_bug.cgi?id=196387
1766
1767         Reviewed by Filip Pizlo.
1768
1769         This patch teaches JS to call Wasm without going through the native thunk.
1770         Currently, we emit a JIT "JS" callee stub which marshals arguments from
1771         JS to Wasm. Like the native version of this, this thunk is responsible
1772         for saving and restoring the VM's current Wasm context. Instead of emitting
1773         an exception handler, we also teach the unwinder how to read the previous
1774         wasm context to restore it as it unwindws past this frame.
1775         
1776         This patch is straight forward, and leaves some areas for perf improvement:
1777         - We can teach the DFG/FTL to directly use the Wasm calling convention when
1778           it knows it's calling a single Wasm function. This way we don't shuffle
1779           registers to the stack and then back into registers.
1780         - We bail out to the slow path for mismatched arity. I opened a bug to fix
1781           optimize arity check failures: https://bugs.webkit.org/show_bug.cgi?id=196564
1782         - We bail out to the slow path Double JSValues flowing into i32 arguments.
1783           We should teach this thunk how to do that conversion directly.
1784         
1785         This patch also refactors the code to explicitly have a single pinned size register.
1786         We used pretend in some places that we could have more than one pinned size register.
1787         However, there was other code that just asserted the size was one. This patch just rips
1788         out this code since we never moved to having more than one pinned size register. Doing
1789         this refactoring cleans up the various places where we set up the size register.
1790         
1791         This patch is a 50-60% progression on JetStream 2's richards-wasm.
1792
1793         * JavaScriptCore.xcodeproj/project.pbxproj:
1794         * Sources.txt:
1795         * assembler/MacroAssemblerCodeRef.h:
1796         (JSC::MacroAssemblerCodeRef::operator=):
1797         (JSC::MacroAssemblerCodeRef::MacroAssemblerCodeRef):
1798         * interpreter/Interpreter.cpp:
1799         (JSC::UnwindFunctor::operator() const):
1800         (JSC::UnwindFunctor::copyCalleeSavesToEntryFrameCalleeSavesBuffer const):
1801         * interpreter/StackVisitor.cpp:
1802         (JSC::StackVisitor::Frame::calleeSaveRegistersForUnwinding):
1803         (JSC::StackVisitor::Frame::calleeSaveRegisters): Deleted.
1804         * interpreter/StackVisitor.h:
1805         * jit/JITOperations.cpp:
1806         * jit/RegisterSet.cpp:
1807         (JSC::RegisterSet::runtimeTagRegisters):
1808         (JSC::RegisterSet::specialRegisters):
1809         (JSC::RegisterSet::runtimeRegisters): Deleted.
1810         * jit/RegisterSet.h:
1811         * jit/Repatch.cpp:
1812         (JSC::linkPolymorphicCall):
1813         * runtime/JSFunction.cpp:
1814         (JSC::getCalculatedDisplayName):
1815         * runtime/JSGlobalObject.cpp:
1816         (JSC::JSGlobalObject::init):
1817         (JSC::JSGlobalObject::visitChildren):
1818         * runtime/JSGlobalObject.h:
1819         (JSC::JSGlobalObject::jsToWasmICCalleeStructure const):
1820         * runtime/VM.cpp:
1821         (JSC::VM::VM):
1822         * runtime/VM.h:
1823         * wasm/WasmAirIRGenerator.cpp:
1824         (JSC::Wasm::AirIRGenerator::AirIRGenerator):
1825         (JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState):
1826         (JSC::Wasm::AirIRGenerator::addCallIndirect):
1827         * wasm/WasmB3IRGenerator.cpp:
1828         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
1829         (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
1830         (JSC::Wasm::B3IRGenerator::addCallIndirect):
1831         * wasm/WasmBinding.cpp:
1832         (JSC::Wasm::wasmToWasm):
1833         * wasm/WasmContext.h:
1834         (JSC::Wasm::Context::pointerToInstance):
1835         * wasm/WasmContextInlines.h:
1836         (JSC::Wasm::Context::store):
1837         * wasm/WasmMemoryInformation.cpp:
1838         (JSC::Wasm::getPinnedRegisters):
1839         (JSC::Wasm::PinnedRegisterInfo::get):
1840         (JSC::Wasm::PinnedRegisterInfo::PinnedRegisterInfo):
1841         * wasm/WasmMemoryInformation.h:
1842         (JSC::Wasm::PinnedRegisterInfo::toSave const):
1843         * wasm/WasmOMGPlan.cpp:
1844         (JSC::Wasm::OMGPlan::work):
1845         * wasm/js/JSToWasm.cpp:
1846         (JSC::Wasm::createJSToWasmWrapper):
1847         * wasm/js/JSToWasmICCallee.cpp: Added.
1848         (JSC::JSToWasmICCallee::create):
1849         (JSC::JSToWasmICCallee::createStructure):
1850         (JSC::JSToWasmICCallee::visitChildren):
1851         * wasm/js/JSToWasmICCallee.h: Added.
1852         (JSC::JSToWasmICCallee::function):
1853         (JSC::JSToWasmICCallee::JSToWasmICCallee):
1854         * wasm/js/WebAssemblyFunction.cpp:
1855         (JSC::WebAssemblyFunction::useTagRegisters const):
1856         (JSC::WebAssemblyFunction::calleeSaves const):
1857         (JSC::WebAssemblyFunction::usedCalleeSaveRegisters const):
1858         (JSC::WebAssemblyFunction::previousInstanceOffset const):
1859         (JSC::WebAssemblyFunction::previousInstance):
1860         (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
1861         (JSC::WebAssemblyFunction::visitChildren):
1862         (JSC::WebAssemblyFunction::destroy):
1863         * wasm/js/WebAssemblyFunction.h:
1864         * wasm/js/WebAssemblyFunctionHeapCellType.cpp: Added.
1865         (JSC::WebAssemblyFunctionDestroyFunc::operator() const):
1866         (JSC::WebAssemblyFunctionHeapCellType::WebAssemblyFunctionHeapCellType):
1867         (JSC::WebAssemblyFunctionHeapCellType::~WebAssemblyFunctionHeapCellType):
1868         (JSC::WebAssemblyFunctionHeapCellType::finishSweep):
1869         (JSC::WebAssemblyFunctionHeapCellType::destroy):
1870         * wasm/js/WebAssemblyFunctionHeapCellType.h: Added.
1871         * wasm/js/WebAssemblyPrototype.h:
1872
1873 2019-04-04  Yusuke Suzuki  <ysuzuki@apple.com>
1874
1875         [JSC] Pass CodeOrigin to FuzzerAgent
1876         https://bugs.webkit.org/show_bug.cgi?id=196590
1877
1878         Reviewed by Saam Barati.
1879
1880         Pass CodeOrigin instead of bytecodeIndex. CodeOrigin includes richer information (InlineCallFrame*).
1881         We also mask prediction with SpecBytecodeTop in DFGByteCodeParser. The fuzzer can produce any SpeculatedTypes,
1882         but DFGByteCodeParser should only see predictions that can be actually produced from the bytecode execution.
1883
1884         * dfg/DFGByteCodeParser.cpp:
1885         (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
1886         * runtime/FuzzerAgent.cpp:
1887         (JSC::FuzzerAgent::getPrediction):
1888         * runtime/FuzzerAgent.h:
1889         * runtime/RandomizingFuzzerAgent.cpp:
1890         (JSC::RandomizingFuzzerAgent::getPrediction):
1891         * runtime/RandomizingFuzzerAgent.h:
1892
1893 2019-04-04  Caio Lima  <ticaiolima@gmail.com>
1894
1895         [JSC] We should consider moving UnlinkedFunctionExecutable::m_parentScopeTDZVariables to RareData
1896         https://bugs.webkit.org/show_bug.cgi?id=194944
1897
1898         Reviewed by Keith Miller.
1899
1900         Based on profile data collected on JetStream2, Speedometer 2 and
1901         other benchmarks, it is very rare having non-empty
1902         UnlinkedFunctionExecutable::m_parentScopeTDZVariables.
1903
1904         - Data collected from Speedometer2
1905             Total number of UnlinkedFunctionExecutable: 39463
1906             Total number of non-empty parentScopeTDZVars: 428 (~1%)
1907
1908         - Data collected from JetStream2
1909             Total number of UnlinkedFunctionExecutable: 83715
1910             Total number of non-empty parentScopeTDZVars: 5285 (~6%)
1911
1912         We also collected numbers on 6 of top 10 Alexia sites.
1913
1914         - Data collected from youtube.com
1915             Total number of UnlinkedFunctionExecutable: 29599
1916             Total number of non-empty parentScopeTDZVars: 97 (~0.3%)
1917
1918         - Data collected from twitter.com
1919             Total number of UnlinkedFunctionExecutable: 23774
1920             Total number of non-empty parentScopeTDZVars: 172 (~0.7%)
1921
1922         - Data collected from google.com
1923             Total number of UnlinkedFunctionExecutable: 33209
1924             Total number of non-empty parentScopeTDZVars: 174 (~0.5%)
1925
1926         - Data collected from amazon.com:
1927             Total number of UnlinkedFunctionExecutable: 15182
1928             Total number of non-empty parentScopeTDZVars: 166 (~1%)
1929
1930         - Data collected from facebook.com:
1931             Total number of UnlinkedFunctionExecutable: 54443
1932             Total number of non-empty parentScopeTDZVars: 269 (~0.4%)
1933
1934         - Data collected from netflix.com:
1935             Total number of UnlinkedFunctionExecutable: 39266
1936             Total number of non-empty parentScopeTDZVars: 97 (~0.2%)
1937
1938         Considering such numbers, this patch is moving `m_parentScopeTDZVariables`
1939         to RareData. This decreases sizeof(UnlinkedFunctionExecutable) by
1940         16 bytes. With this change, now UnlinkedFunctionExecutable constructors
1941         receives an `Optional<VariableEnvironmentMap::Handle>` and only stores
1942         it when `value != WTF::nullopt`. We also changed
1943         UnlinkedFunctionExecutable::parentScopeTDZVariables() and it returns
1944         `VariableEnvironment()` whenever the Executable doesn't have RareData,
1945         or VariableEnvironmentMap::Handle is unitialized. This is required
1946         because RareData is instantiated when any of its field is stored and
1947         we can have an unitialized `Handle` even on cases when parentScopeTDZVariables
1948         is `WTF::nullopt`.
1949
1950         Results on memory usage on JetStrem2 is neutral.
1951
1952             Mean of memory peak on ToT: 4258633728 bytes (confidence interval: 249720072.95)
1953             Mean of memory peak on Changes: 4367325184 bytes (confidence interval: 321285583.61)
1954
1955         * builtins/BuiltinExecutables.cpp:
1956         (JSC::BuiltinExecutables::createExecutable):
1957         * bytecode/UnlinkedFunctionExecutable.cpp:
1958         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
1959         * bytecode/UnlinkedFunctionExecutable.h:
1960         * bytecompiler/BytecodeGenerator.cpp:
1961         (JSC::BytecodeGenerator::getVariablesUnderTDZ):
1962
1963         BytecodeGenerator::getVariablesUnderTDZ now also caches if m_cachedVariablesUnderTDZ
1964         is empty, so we can properly return `WTF::nullopt` without the
1965         reconstruction of a VariableEnvironment to check if it is empty.
1966
1967         * bytecompiler/BytecodeGenerator.h:
1968         (JSC::BytecodeGenerator::makeFunction):
1969         * parser/VariableEnvironment.h:
1970         (JSC::VariableEnvironment::isEmpty const):
1971         * runtime/CachedTypes.cpp:
1972         (JSC::CachedCompactVariableMapHandle::decode const):
1973
1974         It returns an unitialized Handle when there is no
1975         CompactVariableEnvironment. This can happen when RareData is ensured
1976         because of another field.
1977
1978         (JSC::CachedFunctionExecutableRareData::encode):
1979         (JSC::CachedFunctionExecutableRareData::decode const):
1980         (JSC::CachedFunctionExecutable::encode):
1981         (JSC::CachedFunctionExecutable::decode const):
1982         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
1983         * runtime/CodeCache.cpp:
1984
1985         Instead of creating a dummyVariablesUnderTDZ, we simply pass
1986         WTF::nullopt.
1987
1988         (JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
1989
1990 2019-04-04  Tadeu Zagallo  <tzagallo@apple.com>
1991
1992         Cache bytecode for jsc.cpp helpers and fix CachedStringImpl
1993         https://bugs.webkit.org/show_bug.cgi?id=196409
1994
1995         Reviewed by Saam Barati.
1996
1997         Some of the helpers in jsc.cpp, such as `functionRunString`, were stll using
1998         using `makeSource` instead of `jscSource`, which does not use the ShellSourceProvider
1999         and therefore does not write the bytecode cache to disk.
2000
2001         Changing that revealed a bug in bytecode cache. The Encoder keeps a mapping
2002         of pointers to offsets of already cached objects, in order to avoid caching
2003         the same object twice. Similarly, the Decoder keeps a mapping from offsets
2004         to pointers, in order to avoid creating multiple objects in memory for the
2005         same cached object. The following was happening:
2006         1) A StringImpl* S was cached as CachedPtr<CachedStringImpl> at offset O. We add
2007         an entry in the Encoder mapping that S has already been encoded at O.
2008         2) We cache StringImpl* S again, but now as CachedPtr<CachedUniquedStringImpl>.
2009         We find an entry in the Encoder mapping for S, and return the offset O. However,
2010         the object cached at O is a CachedPtr<CachedStringImpl> (i.e. not Uniqued).
2011
2012         3) When decoding, there are 2 possibilities:
2013         3.1) We find S for the first time through a CachedPtr<CachedStringImpl>. In
2014         this case, everything works as expected since we add an entry in the decoder
2015         mapping from the offset O to the decoded StringImpl* S. The next time we find
2016         S through the uniqued version, we'll return the already decoded S.
2017         3.2) We find S through a CachedPtr<CachedUniquedStringImpl>. Now we have a
2018         problem, since the CachedPtr has the offset of a CachedStringImpl (not uniqued),
2019         which has a different shape and we crash.
2020
2021         We fix this by making CachedStringImpl and CachedUniquedStringImpl share the
2022         same implementation. Since it doesn't matter whether a string is uniqued for
2023         encoding, and we always decode strings as uniqued either way, they can be used
2024         interchangeably.
2025
2026         * jsc.cpp:
2027         (functionRunString):
2028         (functionLoadString):
2029         (functionDollarAgentStart):
2030         (functionCheckModuleSyntax):
2031         (runInteractive):
2032         * runtime/CachedTypes.cpp:
2033         (JSC::CachedUniquedStringImplBase::decode const):
2034         (JSC::CachedFunctionExecutable::rareData const):
2035         (JSC::CachedCodeBlock::rareData const):
2036         (JSC::CachedFunctionExecutable::encode):
2037         (JSC::CachedCodeBlock<CodeBlockType>::encode):
2038         (JSC::CachedUniquedStringImpl::encode): Deleted.
2039         (JSC::CachedUniquedStringImpl::decode const): Deleted.
2040         (JSC::CachedStringImpl::encode): Deleted.
2041         (JSC::CachedStringImpl::decode const): Deleted.
2042
2043 2019-04-04  Tadeu Zagallo  <tzagallo@apple.com>
2044
2045         UnlinkedCodeBlock constructor from cache should initialize m_didOptimize
2046         https://bugs.webkit.org/show_bug.cgi?id=196396
2047
2048         Reviewed by Saam Barati.
2049
2050         The UnlinkedCodeBlock constructor in CachedTypes was missing the initialization
2051         for m_didOptimize, which leads to crashes in CodeBlock::thresholdForJIT.
2052
2053         * runtime/CachedTypes.cpp:
2054         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
2055
2056 2019-04-03  Yusuke Suzuki  <ysuzuki@apple.com>
2057
2058         Unreviewed, rolling in r243843 with the build fix
2059         https://bugs.webkit.org/show_bug.cgi?id=196586
2060
2061         * runtime/Options.cpp:
2062         (JSC::recomputeDependentOptions):
2063         * runtime/Options.h:
2064         * runtime/RandomizingFuzzerAgent.cpp:
2065         (JSC::RandomizingFuzzerAgent::getPrediction):
2066
2067 2019-04-03  Ryan Haddad  <ryanhaddad@apple.com>
2068
2069         Unreviewed, rolling out r243843.
2070
2071         Broke CLoop and Windows builds.
2072
2073         Reverted changeset:
2074
2075         "[JSC] Add dump feature for RandomizingFuzzerAgent"
2076         https://bugs.webkit.org/show_bug.cgi?id=196586
2077         https://trac.webkit.org/changeset/243843
2078
2079 2019-04-03  Robin Morisset  <rmorisset@apple.com>
2080
2081         B3 should use associativity to optimize expression trees
2082         https://bugs.webkit.org/show_bug.cgi?id=194081
2083
2084         Reviewed by Filip Pizlo.
2085
2086         This patch adds a new B3 pass, that tries to find and optimize expression trees made purely of any one associative and commutative operator (Add/Mul/BitOr/BitAnd/BitXor).
2087         The pass only runs in O2, and runs once, after lowerMacros and just before a run of B3ReduceStrength (which helps clean up the dead code it tends to leave behind).
2088         I had to separate killDeadCode out of B3ReduceStrength (as a new B3EliminateDeadCode pass) to run it before B3OptimizeAssociativeExpressionTrees, as otherwise it is stopped by high use counts
2089         inherited from CSE.
2090         This extra run of DCE is by itself a win, most notably on microbenchmarks/instanceof-always-hit-two (1.5x faster), and on microbenchmarks/licm-dragons(-out-of-bounds) (both get 1.16x speedup).
2091         I suspect it is because it runs between CSE and tail-dedup, and as a result allows a lot more tail-dedup to occur.
2092
2093         The pass is currently extremely conservative, not trying anything if it would cause _any_ code duplication.
2094         For this purpose, it starts by computing use counts for the potentially interesting nodes (those with the right opcodes), and segregate them into expression trees.
2095         The root of an expression tree is a node that is either used in multiple places, or is used by a value with a different opcode.
2096         The leaves of an expression tree are nodes that are either used in multiple places, or have a different opcode.
2097         All constant leaves of a tree are combined, as well as all leaves that are identical. What remains is then laid out into a balanced binary tree, hopefully maximizing ILP.
2098
2099         This optimization was implemented as a stand-alone pass and not as part of B3ReduceStrength mostly because it needs use counts to avoid code duplication.
2100         It also benefits from finding all tree roots first, and not trying to repeatedly optimize subtrees.
2101
2102         I added several tests to testB3 with varying patterns of trees. It is also tested in a less focused way by lots of older tests.
2103
2104         In the future this pass could be expanded to allow some bounded amount of code duplication, and merging more leaves (e.g. Mul(a, 3) and a in an Add tree, into Mul(a, 4))
2105         The latter will need exposing the peephole optimizations out of B3ReduceStrength to avoid duplicating code.
2106
2107         * JavaScriptCore.xcodeproj/project.pbxproj:
2108         * Sources.txt:
2109         * b3/B3Common.cpp:
2110         (JSC::B3::shouldDumpIR):
2111         (JSC::B3::shouldDumpIRAtEachPhase):
2112         * b3/B3Common.h:
2113         * b3/B3EliminateDeadCode.cpp: Added.
2114         (JSC::B3::EliminateDeadCode::run):
2115         (JSC::B3::eliminateDeadCode):
2116         * b3/B3EliminateDeadCode.h: Added.
2117         (JSC::B3::EliminateDeadCode::EliminateDeadCode):
2118         * b3/B3Generate.cpp:
2119         (JSC::B3::generateToAir):
2120         * b3/B3OptimizeAssociativeExpressionTrees.cpp: Added.
2121         (JSC::B3::OptimizeAssociativeExpressionTrees::OptimizeAssociativeExpressionTrees):
2122         (JSC::B3::OptimizeAssociativeExpressionTrees::neutralElement):
2123         (JSC::B3::OptimizeAssociativeExpressionTrees::isAbsorbingElement):
2124         (JSC::B3::OptimizeAssociativeExpressionTrees::combineConstants):
2125         (JSC::B3::OptimizeAssociativeExpressionTrees::emitValue):
2126         (JSC::B3::OptimizeAssociativeExpressionTrees::optimizeRootedTree):
2127         (JSC::B3::OptimizeAssociativeExpressionTrees::run):
2128         (JSC::B3::optimizeAssociativeExpressionTrees):
2129         * b3/B3OptimizeAssociativeExpressionTrees.h: Added.
2130         * b3/B3ReduceStrength.cpp:
2131         * b3/B3Value.cpp:
2132         (JSC::B3::Value::replaceWithIdentity):
2133         * b3/testb3.cpp:
2134         (JSC::B3::testBitXorTreeArgs):
2135         (JSC::B3::testBitXorTreeArgsEven):
2136         (JSC::B3::testBitXorTreeArgImm):
2137         (JSC::B3::testAddTreeArg32):
2138         (JSC::B3::testMulTreeArg32):
2139         (JSC::B3::testBitAndTreeArg32):
2140         (JSC::B3::testBitOrTreeArg32):
2141         (JSC::B3::run):
2142
2143 2019-04-03  Yusuke Suzuki  <ysuzuki@apple.com>
2144
2145         [JSC] Add dump feature for RandomizingFuzzerAgent
2146         https://bugs.webkit.org/show_bug.cgi?id=196586
2147
2148         Reviewed by Saam Barati.
2149
2150         Towards deterministic tests for the results from randomizing fuzzer agent, this patch adds Options::dumpRandomizingFuzzerAgentPredictions, which dumps the generated types.
2151         The results is like this.
2152
2153             getPrediction name:(#C2q9xD),bytecodeIndex:(22),original:(Array),generated:(OtherObj|Array|Float64Array|BigInt|NonIntAsDouble)
2154             getPrediction name:(makeUnwriteableUnconfigurableObject#AiEJv1),bytecodeIndex:(14),original:(OtherObj),generated:(Final|Uint8Array|Float64Array|SetObject|WeakSetObject|BigInt|NonIntAsDouble)
2155
2156         * runtime/Options.cpp:
2157         (JSC::recomputeDependentOptions):
2158         * runtime/Options.h:
2159         * runtime/RandomizingFuzzerAgent.cpp:
2160         (JSC::RandomizingFuzzerAgent::getPrediction):
2161
2162 2019-04-03  Myles C. Maxfield  <mmaxfield@apple.com>
2163
2164         -apple-trailing-word is needed for browser detection
2165         https://bugs.webkit.org/show_bug.cgi?id=196575
2166
2167         Unreviewed.
2168
2169         * Configurations/FeatureDefines.xcconfig:
2170
2171 2019-04-03  Michael Saboff  <msaboff@apple.com>
2172
2173         REGRESSION (r243642): com.apple.JavaScriptCore crash in JSC::RegExpObject::execInline
2174         https://bugs.webkit.org/show_bug.cgi?id=196477
2175
2176         Reviewed by Keith Miller.
2177
2178         The problem here is that when we advance the index by 2 for a character class that only
2179         has non-BMP characters, we might go past the end of the string.  This can happen for
2180         greedy counted character classes that are part of a alternative where there is one
2181         character to match after the greedy non-BMP character class.
2182
2183         The "do we have string left to match" check at the top of the JIT loop for the counted
2184         character class checks to see if index is not equal to the string length.  For non-BMP
2185         character classes, we need to check to see if there are at least 2 characters left.
2186         Therefore we now temporarily add 1 to the current index before comparing.  This checks
2187         to see if there are iat least 2 characters left to match, instead of 1.
2188
2189         * yarr/YarrJIT.cpp:
2190         (JSC::Yarr::YarrGenerator::generateCharacterClassGreedy):
2191         (JSC::Yarr::YarrGenerator::backtrackCharacterClassNonGreedy):
2192
2193 2019-04-03  Yusuke Suzuki  <ysuzuki@apple.com>
2194
2195         [JSC] Exception verification crash on operationArrayIndexOfValueInt32OrContiguous
2196         https://bugs.webkit.org/show_bug.cgi?id=196574
2197
2198         Reviewed by Saam Barati.
2199
2200         This patch adds missing exception check in operationArrayIndexOfValueInt32OrContiguous.
2201
2202         * dfg/DFGOperations.cpp:
2203
2204 2019-04-03  Don Olmstead  <don.olmstead@sony.com>
2205
2206         [CMake][WTF] Mirror XCode header directories
2207         https://bugs.webkit.org/show_bug.cgi?id=191662
2208
2209         Reviewed by Konstantin Tokarev.
2210
2211         Use WTFFramework as a dependency and include frameworks/WTF.cmake for AppleWin internal
2212         builds.
2213
2214         * CMakeLists.txt:
2215         * shell/CMakeLists.txt:
2216
2217 2019-04-03  Yusuke Suzuki  <ysuzuki@apple.com>
2218
2219         [JSC] Add FuzzerAgent, which has a hooks to get feedback & inject fuzz data into JSC
2220         https://bugs.webkit.org/show_bug.cgi?id=196530
2221
2222         Reviewed by Saam Barati.
2223
2224         This patch adds FuzzerAgent interface and simple RandomizingFuzzerAgent to JSC.
2225         This RandomizingFuzzerAgent returns random SpeculatedType for value profiling to find
2226         the issues in JSC. The seed for randomization can be specified by seedOfRandomizingFuzzerAgent.
2227
2228         I ran this with seedOfRandomizingFuzzerAgent=1 last night and it finds 3 failures in the current JSC tests,
2229         they should be fixed in subsequent patches.
2230
2231         * CMakeLists.txt:
2232         * JavaScriptCore.xcodeproj/project.pbxproj:
2233         * Sources.txt:
2234         * dfg/DFGByteCodeParser.cpp:
2235         (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
2236         * runtime/FuzzerAgent.cpp: Added.
2237         (JSC::FuzzerAgent::~FuzzerAgent):
2238         (JSC::FuzzerAgent::getPrediction):
2239         * runtime/FuzzerAgent.h: Added.
2240         * runtime/JSGlobalObjectFunctions.cpp:
2241         * runtime/Options.h:
2242         * runtime/RandomizingFuzzerAgent.cpp: Added.
2243         (JSC::RandomizingFuzzerAgent::RandomizingFuzzerAgent):
2244         (JSC::RandomizingFuzzerAgent::getPrediction):
2245         * runtime/RandomizingFuzzerAgent.h: Added.
2246         * runtime/RegExpCachedResult.h:
2247         * runtime/RegExpGlobalData.cpp:
2248         * runtime/VM.cpp:
2249         (JSC::VM::VM):
2250         * runtime/VM.h:
2251         (JSC::VM::fuzzerAgent const):
2252         (JSC::VM::setFuzzerAgent):
2253
2254 2019-04-03  Myles C. Maxfield  <mmaxfield@apple.com>
2255
2256         Remove support for -apple-trailing-word
2257         https://bugs.webkit.org/show_bug.cgi?id=196525
2258
2259         Reviewed by Zalan Bujtas.
2260
2261         This CSS property is nonstandard and not used.
2262
2263         * Configurations/FeatureDefines.xcconfig:
2264
2265 2019-04-03  Joseph Pecoraro  <pecoraro@apple.com>
2266
2267         Web Inspector: Remote Inspector indicate callback should always happen on the main thread
2268         https://bugs.webkit.org/show_bug.cgi?id=196513
2269         <rdar://problem/49498284>
2270
2271         Reviewed by Devin Rousso.
2272
2273         * inspector/remote/cocoa/RemoteInspectorCocoa.mm:
2274         (Inspector::RemoteInspector::receivedIndicateMessage):
2275         When we have a WebThread, don't just run on the WebThread,
2276         run on the MainThread with the WebThreadLock.
2277
2278 2019-04-02  Michael Saboff  <msaboff@apple.com>
2279
2280         Crash in Options::setOptions() using --configFile option and libgmalloc
2281         https://bugs.webkit.org/show_bug.cgi?id=196506
2282
2283         Reviewed by Keith Miller.
2284
2285         Changed to call CString::data() while making the call to Options::setOptions().  This keeps
2286         the implicit CString temporary alive until after setOptions() returns.
2287
2288         * runtime/ConfigFile.cpp:
2289         (JSC::ConfigFile::parse):
2290
2291 2019-04-02  Fujii Hironori  <Hironori.Fujii@sony.com>
2292
2293         [CMake] WEBKIT_MAKE_FORWARDING_HEADERS shouldn't use POST_BUILD to copy generated headers
2294         https://bugs.webkit.org/show_bug.cgi?id=182757
2295
2296         Reviewed by Don Olmstead.
2297
2298         * CMakeLists.txt: Do not use DERIVED_SOURCE_DIRECTORIES parameter
2299         of WEBKIT_MAKE_FORWARDING_HEADERS. Added generated headers to
2300         JavaScriptCore_PRIVATE_FRAMEWORK_HEADERS.
2301
2302 2019-04-02  Saam barati  <sbarati@apple.com>
2303
2304         Add a ValueRepReduction phase
2305         https://bugs.webkit.org/show_bug.cgi?id=196234
2306
2307         Reviewed by Filip Pizlo.
2308
2309         This patch adds a ValueRepReduction phase. The main idea here is
2310         to try to reduce DoubleRep(RealNumberUse:ValueRep(DoubleRepUse:@x))
2311         to just be @x. This patch handles such above strengh reduction rules
2312         as long as we prove that all users of the ValueRep can be converted
2313         to using the incoming double value. That way we prevent introducing
2314         a parallel live range for the double value.
2315         
2316         This patch tracks the uses of the ValueRep through Phi variables,
2317         so we can convert entire Phi variables to being Double instead
2318         of JSValue if the Phi also has only double uses.
2319         
2320         This is implemented through a simple escape analysis. DoubleRep(RealNumberUse:)
2321         and OSR exit hints are not counted as escapes. All other uses are counted
2322         as escapes. Connected Phi graphs are converted to being Double only if the
2323         entire graph is ok with the result being Double.
2324         
2325         Some ways we could extend this phase in the future:
2326         - There are a lot of DoubleRep(NumberUse:@ValueRep(@x)) uses. This ensures
2327           that the result of the DoubleRep of @x is not impure NaN. We could
2328           handle this case if we introduced a PurifyNaN node and replace the DoubleRep
2329           with PurifyNaN(@x). Alternatively, we could see if certain users of this
2330           DoubleRep are okay with impure NaN flowing into them and we'd need to ensure
2331           their output type is always treated as if the input is impure NaN.
2332         - We could do sinking of ValueRep where we think it's profitable. So instead
2333           of an escape making it so we never represent the variable as a Double, we
2334           could make the escape reconstruct the JSValueRep where profitable.
2335         - We can extend this phase to handle Int52Rep if it's profitable.
2336         - We can opt other nodes into accepting incoming Doubles so we no longer
2337           treat them as escapes.
2338         
2339         This patch is somewhere between neutral and a 1% progression on JetStream 2.
2340
2341         * JavaScriptCore.xcodeproj/project.pbxproj:
2342         * Sources.txt:
2343         * dfg/DFGPlan.cpp:
2344         (JSC::DFG::Plan::compileInThreadImpl):
2345         * dfg/DFGValueRepReductionPhase.cpp: Added.
2346         (JSC::DFG::ValueRepReductionPhase::ValueRepReductionPhase):
2347         (JSC::DFG::ValueRepReductionPhase::run):
2348         (JSC::DFG::ValueRepReductionPhase::convertValueRepsToDouble):
2349         (JSC::DFG::performValueRepReduction):
2350         * dfg/DFGValueRepReductionPhase.h: Added.
2351         * runtime/Options.h:
2352
2353 2019-04-01  Yusuke Suzuki  <ysuzuki@apple.com>
2354
2355         [JSC] JSRunLoopTimer::Manager should be small
2356         https://bugs.webkit.org/show_bug.cgi?id=196425
2357
2358         Reviewed by Darin Adler.
2359
2360         Using very large Key or Value in HashMap potentially bloats memory since HashMap pre-allocates large size of
2361         memory ((sizeof(Key) + sizeof(Value)) * N) for its backing storage's array. Using std::unique_ptr<> for JSRunLoopTimer's
2362         PerVMData to keep HashMap's backing store size small.
2363
2364         * runtime/JSRunLoopTimer.cpp:
2365         (JSC::JSRunLoopTimer::Manager::timerDidFire):
2366         (JSC::JSRunLoopTimer::Manager::registerVM):
2367         (JSC::JSRunLoopTimer::Manager::scheduleTimer):
2368         (JSC::JSRunLoopTimer::Manager::cancelTimer):
2369         (JSC::JSRunLoopTimer::Manager::timeUntilFire):
2370         (JSC::JSRunLoopTimer::Manager::didChangeRunLoop):
2371         * runtime/JSRunLoopTimer.h:
2372
2373 2019-04-01  Stephan Szabo  <stephan.szabo@sony.com>
2374
2375         [PlayStation] Add initialization for JSC shell for PlayStation port
2376         https://bugs.webkit.org/show_bug.cgi?id=195411
2377
2378         Reviewed by Ross Kirsling.
2379
2380         Add ps options
2381
2382         * shell/PlatformPlayStation.cmake: Added.
2383         * shell/playstation/Initializer.cpp: Added.
2384         (initializer):
2385
2386 2019-04-01  Michael Catanzaro  <mcatanzaro@igalia.com>
2387
2388         Stop trying to support building JSC with clang 3.8
2389         https://bugs.webkit.org/show_bug.cgi?id=195947
2390         <rdar://problem/49069219>
2391
2392         Reviewed by Darin Adler.
2393
2394         It seems WebKit hasn't built with clang 3.8 in a while, no devs are using this compiler, we
2395         don't know how much effort it would be to make JSC work again, and it's making the code
2396         worse. Remove my hacks to support clang 3.8 from JSC.
2397
2398         * bindings/ScriptValue.cpp:
2399         (Inspector::jsToInspectorValue):
2400         * bytecode/GetterSetterAccessCase.cpp:
2401         (JSC::GetterSetterAccessCase::create):
2402         (JSC::GetterSetterAccessCase::clone const):
2403         * bytecode/InstanceOfAccessCase.cpp:
2404         (JSC::InstanceOfAccessCase::clone const):
2405         * bytecode/IntrinsicGetterAccessCase.cpp:
2406         (JSC::IntrinsicGetterAccessCase::clone const):
2407         * bytecode/ModuleNamespaceAccessCase.cpp:
2408         (JSC::ModuleNamespaceAccessCase::clone const):
2409         * bytecode/ProxyableAccessCase.cpp:
2410         (JSC::ProxyableAccessCase::clone const):
2411
2412 2019-03-31  Yusuke Suzuki  <ysuzuki@apple.com>
2413
2414         [JSC] Butterfly allocation from LargeAllocation should try "realloc" behavior if collector thread is not active
2415         https://bugs.webkit.org/show_bug.cgi?id=196160
2416
2417         Reviewed by Saam Barati.
2418
2419         "realloc" can be effective in terms of peak/current memory footprint when realloc succeeds because,
2420
2421         1. It does not allocate additional memory while expanding a vector
2422         2. It does not deallocate an old memory, just reusing the current memory by expanding, so that memory footprint is tight even before scavenging
2423
2424         We found that we can "realloc" large butterflies in certain conditions are met because,
2425
2426         1. If it goes to LargeAllocation, this memory region is never reused until GC sweeps it.
2427         2. Butterflies are owned by owner JSObjects, so we know the lifetime of Butterflies.
2428
2429         This patch attempts to use "realloc" onto butterflies if,
2430
2431         1. Butterflies are allocated in LargeAllocation kind
2432         2. Concurrent collector is not active
2433         3. Butterflies do not have property storage
2434
2435         The condition (2) is required to avoid deallocating butterflies while the concurrent collector looks into it. The condition (3) is
2436         also required to avoid deallocating butterflies while the concurrent compiler looks into it.
2437
2438         We also change LargeAllocation mechanism to using "malloc" and "free" instead of "posix_memalign". This allows us to use "realloc"
2439         safely in all the platforms. Since LargeAllocation uses alignment to distinguish LargeAllocation and MarkedBlock, we manually adjust
2440         16B alignment by allocating 8B more memory in "malloc".
2441
2442         Speedometer2 and JetStream2 are neutral. RAMification shows about 1% progression (even in some of JIT tests).
2443
2444         * heap/AlignedMemoryAllocator.h:
2445         * heap/CompleteSubspace.cpp:
2446         (JSC::CompleteSubspace::tryAllocateSlow):
2447         (JSC::CompleteSubspace::reallocateLargeAllocationNonVirtual):
2448         * heap/CompleteSubspace.h:
2449         * heap/FastMallocAlignedMemoryAllocator.cpp:
2450         (JSC::FastMallocAlignedMemoryAllocator::tryAllocateMemory):
2451         (JSC::FastMallocAlignedMemoryAllocator::freeMemory):
2452         (JSC::FastMallocAlignedMemoryAllocator::tryReallocateMemory):
2453         * heap/FastMallocAlignedMemoryAllocator.h:
2454         * heap/GigacageAlignedMemoryAllocator.cpp:
2455         (JSC::GigacageAlignedMemoryAllocator::tryAllocateMemory):
2456         (JSC::GigacageAlignedMemoryAllocator::freeMemory):
2457         (JSC::GigacageAlignedMemoryAllocator::tryReallocateMemory):
2458         * heap/GigacageAlignedMemoryAllocator.h:
2459         * heap/IsoAlignedMemoryAllocator.cpp:
2460         (JSC::IsoAlignedMemoryAllocator::tryAllocateMemory):
2461         (JSC::IsoAlignedMemoryAllocator::freeMemory):
2462         (JSC::IsoAlignedMemoryAllocator::tryReallocateMemory):
2463         * heap/IsoAlignedMemoryAllocator.h:
2464         * heap/LargeAllocation.cpp:
2465         (JSC::isAlignedForLargeAllocation):
2466         (JSC::LargeAllocation::tryCreate):
2467         (JSC::LargeAllocation::tryReallocate):
2468         (JSC::LargeAllocation::LargeAllocation):
2469         (JSC::LargeAllocation::destroy):
2470         * heap/LargeAllocation.h:
2471         (JSC::LargeAllocation::indexInSpace):
2472         (JSC::LargeAllocation::setIndexInSpace):
2473         (JSC::LargeAllocation::basePointer const):
2474         * heap/MarkedSpace.cpp:
2475         (JSC::MarkedSpace::sweepLargeAllocations):
2476         (JSC::MarkedSpace::prepareForConservativeScan):
2477         * heap/WeakSet.h:
2478         (JSC::WeakSet::isTriviallyDestructible const):
2479         * runtime/Butterfly.h:
2480         * runtime/ButterflyInlines.h:
2481         (JSC::Butterfly::reallocArrayRightIfPossible):
2482         * runtime/JSObject.cpp:
2483         (JSC::JSObject::ensureLengthSlow):
2484
2485 2019-03-31  Sam Weinig  <weinig@apple.com>
2486
2487         Remove more i386 specific configurations
2488         https://bugs.webkit.org/show_bug.cgi?id=196430
2489
2490         Reviewed by Alexey Proskuryakov.
2491
2492         * Configurations/FeatureDefines.xcconfig:
2493         ENABLE_WEB_AUTHN_macosx can now be enabled unconditionally on macOS.
2494
2495         * Configurations/ToolExecutable.xcconfig:
2496         ARC can be enabled unconditionally now.
2497
2498 2019-03-29  Yusuke Suzuki  <ysuzuki@apple.com>
2499
2500         [JSC] JSWrapperMap should not use Objective-C Weak map (NSMapTable with NSPointerFunctionsWeakMemory) for m_cachedObjCWrappers
2501         https://bugs.webkit.org/show_bug.cgi?id=196392
2502
2503         Reviewed by Saam Barati.
2504
2505         Weak representation in Objective-C is surprisingly costly in terms of memory. We can see that very easy program shows 10KB memory consumption due to
2506         this weak wrapper map in JavaScriptCore.framework. But we do not need this weak map since Objective-C JSValue has a dealloc. We can unregister itself
2507         from the map when it is deallocated without using Objective-C weak mechanism. And since Objective-C JSValue is tightly coupled to a specific JSContext,
2508         and wrapper map is created per JSContext, JSValue wrapper and actual JavaScriptCore value is one-on-one, and [JSValue dealloc] knows which JSContext's
2509         wrapper map holds itself.
2510
2511         1. We do not use Objective-C weak mechanism. We use WTF::HashSet instead. When JSValue is allocated, we register it to JSWrapperMap's HashSet. And unregister
2512            JSValue from this map when JSValue is deallocated.
2513         2. We use HashSet<JSValue> (logically) instead of HashMap<JSValueRef, JSValue> to keep JSValueRef and JSValue relationship. We can achieve it because JSValue
2514            holds JSValueRef inside it.
2515
2516         * API/JSContext.mm:
2517         (-[JSContext removeWrapper:]):
2518         * API/JSContextInternal.h:
2519         * API/JSValue.mm:
2520         (-[JSValue dealloc]):
2521         (-[JSValue initWithValue:inContext:]):
2522         * API/JSWrapperMap.h:
2523         * API/JSWrapperMap.mm:
2524         (WrapperKey::hashTableDeletedValue):
2525         (WrapperKey::WrapperKey):
2526         (WrapperKey::isHashTableDeletedValue const):
2527         (WrapperKey::Hash::hash):
2528         (WrapperKey::Hash::equal):
2529         (WrapperKey::Traits::isEmptyValue):
2530         (WrapperKey::Translator::hash):
2531         (WrapperKey::Translator::equal):
2532         (WrapperKey::Translator::translate):
2533         (-[JSWrapperMap initWithGlobalContextRef:]):
2534         (-[JSWrapperMap dealloc]):
2535         (-[JSWrapperMap objcWrapperForJSValueRef:inContext:]):
2536         (-[JSWrapperMap removeWrapper:]):
2537         * API/tests/testapi.mm:
2538         (testObjectiveCAPIMain):
2539
2540 2019-03-29  Robin Morisset  <rmorisset@apple.com>
2541
2542         B3ReduceStrength should know that Mul distributes over Add and Sub
2543         https://bugs.webkit.org/show_bug.cgi?id=196325
2544
2545         Reviewed by Michael Saboff.
2546
2547         In this patch I add the following patterns to B3ReduceStrength:
2548         - Turn this: Integer Neg(Mul(value, c))
2549           Into this: Mul(value, -c), as long as -c does not overflow
2550         - Turn these: Integer Mul(value, Neg(otherValue)) and Integer Mul(Neg(value), otherValue)
2551           Into this: Neg(Mul(value, otherValue))
2552         - For Op==Add or Sub, turn any of these:
2553              Op(Mul(x1, x2), Mul(x1, x3))
2554              Op(Mul(x2, x1), Mul(x1, x3))
2555              Op(Mul(x1, x2), Mul(x3, x1))
2556              Op(Mul(x2, x1), Mul(x3, x1))
2557           Into this: Mul(x1, Op(x2, x3))
2558
2559         Also includes a trivial change: a similar reduction for the distributivity of BitAnd over BitOr/BitXor now
2560         emits the arguments to BitAnd in the other order, to minimize the probability that we'll spend a full fixpoint step just to flip them.
2561
2562         * b3/B3ReduceStrength.cpp:
2563         * b3/testb3.cpp:
2564         (JSC::B3::testAddMulMulArgs):
2565         (JSC::B3::testMulArgNegArg):
2566         (JSC::B3::testMulNegArgArg):
2567         (JSC::B3::testNegMulArgImm):
2568         (JSC::B3::testSubMulMulArgs):
2569         (JSC::B3::run):
2570
2571 2019-03-29  Yusuke Suzuki  <ysuzuki@apple.com>
2572
2573         [JSC] Remove distancing for LargeAllocation
2574         https://bugs.webkit.org/show_bug.cgi?id=196335
2575
2576         Reviewed by Saam Barati.
2577
2578         In r230226, we removed distancing feature from our GC. This patch removes remaining distancing thing in LargeAllocation.
2579
2580         * heap/HeapCell.h:
2581         * heap/LargeAllocation.cpp:
2582         (JSC::LargeAllocation::tryCreate):
2583         * heap/MarkedBlock.h:
2584
2585 2019-03-29  Myles C. Maxfield  <mmaxfield@apple.com>
2586
2587         Delete WebMetal implementation in favor of WebGPU
2588         https://bugs.webkit.org/show_bug.cgi?id=195418
2589
2590         Reviewed by Dean Jackson.
2591
2592         * Configurations/FeatureDefines.xcconfig:
2593         * inspector/protocol/Canvas.json:
2594         * inspector/scripts/codegen/generator.py:
2595
2596 2019-03-29  Tadeu Zagallo  <tzagallo@apple.com>
2597
2598         Assertion failed in JSC::createError
2599         https://bugs.webkit.org/show_bug.cgi?id=196305
2600         <rdar://problem/49387382>
2601
2602         Reviewed by Saam Barati.
2603
2604         JSC::createError assumes that `errorDescriptionForValue` will either
2605         throw an exception or return a valid description string. However, that
2606         is not true if the value is a rope string and we successfully resolve it,
2607         but later fail to wrap the string in quotes with `tryMakeString`.
2608
2609         * runtime/ExceptionHelpers.cpp:
2610         (JSC::createError):
2611
2612 2019-03-29  Devin Rousso  <drousso@apple.com>
2613
2614         Web Inspector: add fast returns for instrumentation hooks that have no affect before a frontend is connected
2615         https://bugs.webkit.org/show_bug.cgi?id=196382
2616         <rdar://problem/49403417>
2617
2618         Reviewed by Joseph Pecoraro.
2619
2620         Ensure that all instrumentation hooks use `FAST_RETURN_IF_NO_FRONTENDS` or check that
2621         `developerExtrasEnabled`. There should be no activity to/from any inspector objects until
2622         developer extras are enabled.
2623
2624         * inspector/agents/InspectorConsoleAgent.cpp:
2625         (Inspector::InspectorConsoleAgent::startTiming):
2626         (Inspector::InspectorConsoleAgent::stopTiming):
2627         (Inspector::InspectorConsoleAgent::count):
2628         (Inspector::InspectorConsoleAgent::addConsoleMessage):
2629
2630 2019-03-29  Cathie Chen  <cathiechen@igalia.com>
2631
2632         Implement ResizeObserver.
2633         https://bugs.webkit.org/show_bug.cgi?id=157743
2634
2635         Reviewed by Simon Fraser.
2636
2637         Add ENABLE_RESIZE_OBSERVER.
2638
2639         * Configurations/FeatureDefines.xcconfig:
2640
2641 2019-03-28  Michael Saboff  <msaboff@apple.com>
2642
2643         [YARR] Precompute BMP / non-BMP status when constructing character classes
2644         https://bugs.webkit.org/show_bug.cgi?id=196296
2645
2646         Reviewed by Keith Miller.
2647
2648         Changed CharacterClass::m_hasNonBMPCharacters into a character width bit field which
2649         indicateis if the class includes characters from either BMP, non-BMP or both ranges.
2650         This allows the recognizing code to eliminate checks for the width of a matched
2651         characters when the class has only one width.  The character width is needed to
2652         determine if we advance 1 or 2 character.  Also, the pre-computed width of character
2653         classes that contains either all BMP or all non-BMP characters allows the parser to
2654         use fixed widths for terms using those character classes.  Changed both the code gen
2655         scripts and Yarr compiler to compute this bit field during the construction of
2656         character classes.
2657
2658         For JIT'ed code of character classes that contain either all BMP or all non-BMP
2659         characters, we can eliminate the generic check we were doing do compute how much
2660         to advance after sucessfully matching a character in the class.
2661
2662                 Generic isBMP check      BMP only            non-BMP only
2663                 --------------           --------------      --------------
2664                 inc %r9d                 inc %r9d            add $0x2, %r9d
2665                 cmp $0x10000, %eax
2666                 jl isBMP
2667                 cmp %edx, %esi
2668                 jz atEndOfString
2669                 inc %r9d
2670                 inc %esi
2671          isBMP:
2672
2673         For character classes that contained non-BMP characters, we were always generating
2674         the code in the left column.  The middle column is the code we generate for character
2675         classes that contain only BMP characters.  The right column is the code we now
2676         generate if the character class has only non-BMP characters.  In the fix width cases,
2677         we can eliminate both the isBMP check as well as the atEndOfString check.  The
2678         atEndOfstring check is eliminated since we know how many characters this character
2679         class requires and that check can be factored out to the beginning of the current
2680         alternative.  For character classes that contain both BMP and non-BMP characters,
2681         we still generate the generic left column.
2682
2683         This change is a ~8% perf progression on UniPoker and a ~2% improvement on RexBench
2684         as a whole.
2685
2686         * runtime/RegExp.cpp:
2687         (JSC::RegExp::matchCompareWithInterpreter):
2688         * runtime/RegExpInlines.h:
2689         (JSC::RegExp::matchInline):
2690         * yarr/YarrInterpreter.cpp:
2691         (JSC::Yarr::Interpreter::checkCharacterClassDontAdvanceInputForNonBMP):
2692         (JSC::Yarr::Interpreter::matchCharacterClass):
2693         * yarr/YarrJIT.cpp:
2694         (JSC::Yarr::YarrGenerator::optimizeAlternative):
2695         (JSC::Yarr::YarrGenerator::matchCharacterClass):
2696         (JSC::Yarr::YarrGenerator::advanceIndexAfterCharacterClassTermMatch):
2697         (JSC::Yarr::YarrGenerator::tryReadUnicodeCharImpl):
2698         (JSC::Yarr::YarrGenerator::generateCharacterClassOnce):
2699         (JSC::Yarr::YarrGenerator::generateCharacterClassFixed):
2700         (JSC::Yarr::YarrGenerator::generateCharacterClassGreedy):
2701         (JSC::Yarr::YarrGenerator::backtrackCharacterClassGreedy):
2702         (JSC::Yarr::YarrGenerator::generateCharacterClassNonGreedy):
2703         (JSC::Yarr::YarrGenerator::backtrackCharacterClassNonGreedy):
2704         (JSC::Yarr::YarrGenerator::generateEnter):
2705         (JSC::Yarr::YarrGenerator::YarrGenerator):
2706         (JSC::Yarr::YarrGenerator::compile):
2707         * yarr/YarrPattern.cpp:
2708         (JSC::Yarr::CharacterClassConstructor::CharacterClassConstructor):
2709         (JSC::Yarr::CharacterClassConstructor::reset):
2710         (JSC::Yarr::CharacterClassConstructor::charClass):
2711         (JSC::Yarr::CharacterClassConstructor::addSorted):
2712         (JSC::Yarr::CharacterClassConstructor::addSortedRange):
2713         (JSC::Yarr::CharacterClassConstructor::hasNonBMPCharacters):
2714         (JSC::Yarr::CharacterClassConstructor::characterWidths):
2715         (JSC::Yarr::PatternTerm::dump):
2716         (JSC::Yarr::anycharCreate):
2717         * yarr/YarrPattern.h:
2718         (JSC::Yarr::operator|):
2719         (JSC::Yarr::operator&):
2720         (JSC::Yarr::operator|=):
2721         (JSC::Yarr::CharacterClass::CharacterClass):
2722         (JSC::Yarr::CharacterClass::hasNonBMPCharacters):
2723         (JSC::Yarr::CharacterClass::hasOneCharacterSize):
2724         (JSC::Yarr::CharacterClass::hasOnlyNonBMPCharacters):
2725         (JSC::Yarr::PatternTerm::invert const):
2726         (JSC::Yarr::PatternTerm::invert): Deleted.
2727         * yarr/create_regex_tables:
2728         * yarr/generateYarrUnicodePropertyTables.py:
2729
2730 2019-03-28  Saam Barati  <sbarati@apple.com>
2731
2732         BackwardsGraph needs to consider back edges as the backward's root successor
2733         https://bugs.webkit.org/show_bug.cgi?id=195991
2734
2735         Reviewed by Filip Pizlo.
2736
2737         * b3/testb3.cpp:
2738         (JSC::B3::testInfiniteLoopDoesntCauseBadHoisting):
2739         (JSC::B3::run):
2740
2741 2019-03-28  Fujii Hironori  <Hironori.Fujii@sony.com>
2742
2743         Opcode.h(159,27): warning: adding 'unsigned int' to a string does not append to the string [-Wstring-plus-int]
2744         https://bugs.webkit.org/show_bug.cgi?id=196343
2745
2746         Reviewed by Saam Barati.
2747
2748         Clang reports a compilation warning and recommend '&PADDING_STRING[PADDING_STRING_LENGTH]'
2749         instead of 'PADDING_STRING + PADDING_STRING_LENGTH'.
2750
2751         * bytecode/Opcode.cpp:
2752         (JSC::padOpcodeName): Moved padOpcodeName from Opcode.h because
2753         this function is used only in Opcode.cpp. Changed macros
2754         PADDING_STRING and PADDING_STRING_LENGTH to simple variables.
2755         (JSC::compareOpcodePairIndices): Replaced pair with std::pair.
2756         * bytecode/Opcode.h:
2757         (JSC::padOpcodeName): Moved.
2758
2759 2019-03-28  Tadeu Zagallo  <tzagallo@apple.com>
2760
2761         CodeBlock::jettison() should disallow repatching its own calls
2762         https://bugs.webkit.org/show_bug.cgi?id=196359
2763         <rdar://problem/48973663>
2764
2765         Reviewed by Saam Barati.
2766
2767         CodeBlock::jettison() calls CommonData::invalidate, which replaces the `hlt`
2768         instruction with the jump to OSR exit. However, if the `hlt` was immediately
2769         followed by a call to the CodeBlock being jettisoned, we would write over the
2770         OSR exit address while unlinking all the incoming CallLinkInfos later in
2771         CodeBlock::jettison().
2772
2773         Change it so that we set a flag, `clearedByJettison`, in all the CallLinkInfos
2774         owned by the CodeBlock being jettisoned. If the flag is set, we will avoid
2775         repatching the call during unlinking. This is safe because this call will never
2776         be reachable again after the CodeBlock is jettisoned.
2777
2778         * bytecode/CallLinkInfo.cpp:
2779         (JSC::CallLinkInfo::CallLinkInfo):
2780         (JSC::CallLinkInfo::setCallee):
2781         (JSC::CallLinkInfo::clearCallee):
2782         (JSC::CallLinkInfo::setCodeBlock):
2783         (JSC::CallLinkInfo::clearCodeBlock):
2784         * bytecode/CallLinkInfo.h:
2785         (JSC::CallLinkInfo::clearedByJettison):
2786         (JSC::CallLinkInfo::setClearedByJettison):
2787         * bytecode/CodeBlock.cpp:
2788         (JSC::CodeBlock::jettison):
2789         * jit/Repatch.cpp:
2790         (JSC::revertCall):
2791
2792 2019-03-27  Yusuke Suzuki  <ysuzuki@apple.com>
2793
2794         [JSC] Drop VM and Context cache map in JavaScriptCore.framework
2795         https://bugs.webkit.org/show_bug.cgi?id=196341
2796
2797         Reviewed by Saam Barati.
2798
2799         Previously, we created Objective-C weak map to maintain JSVirtualMachine and JSContext wrappers corresponding to VM and JSGlobalObject.
2800         But Objective-C weak map is really memory costly. Even if the entry is only one, it consumes 2.5KB per weak map. Since we can modify
2801         JSC intrusively for JavaScriptCore.framework (and we already did it, like, holding JSWrapperMap in JSGlobalObject), we can just hold
2802         a pointer to a wrapper in VM and JSGlobalObject.
2803
2804         This patch adds void* members to VM and JSGlobalObject, which holds a non-strong reference to a wrapper. When a wrapper is gone, we
2805         clear this pointer too. This removes unnecessary two Objective-C weak maps, and save 5KB.
2806
2807         * API/JSContext.mm:
2808         (-[JSContext initWithVirtualMachine:]):
2809         (-[JSContext dealloc]):
2810         (-[JSContext initWithGlobalContextRef:]):
2811         (-[JSContext wrapperMap]):
2812         (+[JSContext contextWithJSGlobalContextRef:]):
2813         * API/JSVirtualMachine.mm:
2814         (-[JSVirtualMachine initWithContextGroupRef:]):
2815         (-[JSVirtualMachine dealloc]):
2816         (+[JSVirtualMachine virtualMachineWithContextGroupRef:]):
2817         (scanExternalObjectGraph):
2818         (scanExternalRememberedSet):
2819         (initWrapperCache): Deleted.
2820         (wrapperCache): Deleted.
2821         (+[JSVMWrapperCache addWrapper:forJSContextGroupRef:]): Deleted.
2822         (+[JSVMWrapperCache wrapperForJSContextGroupRef:]): Deleted.
2823         (-[JSVirtualMachine contextForGlobalContextRef:]): Deleted.
2824         (-[JSVirtualMachine addContext:forGlobalContextRef:]): Deleted.
2825         * API/JSVirtualMachineInternal.h:
2826         * runtime/JSGlobalObject.h:
2827         (JSC::JSGlobalObject::setAPIWrapper):
2828         (JSC::JSGlobalObject::apiWrapper const):
2829         * runtime/VM.h:
2830
2831 2019-03-28  Tadeu Zagallo  <tzagallo@apple.com>
2832
2833         In-memory code cache should not share bytecode across domains
2834         https://bugs.webkit.org/show_bug.cgi?id=196321
2835
2836         Reviewed by Geoffrey Garen.
2837
2838         Use the SourceProvider's URL to make sure that the hosts match for the
2839         two SourceCodeKeys in operator==.
2840
2841         * parser/SourceCodeKey.h:
2842         (JSC::SourceCodeKey::host const):
2843         (JSC::SourceCodeKey::operator== const):
2844
2845 2019-03-28  Víctor Manuel Jáquez Leal  <vjaquez@igalia.com>
2846
2847         Silence lot of warnings when compiling with clang
2848         https://bugs.webkit.org/show_bug.cgi?id=196310
2849
2850         Reviewed by Michael Catanzaro.
2851
2852         Initialize variable with default constructor.
2853
2854         * API/glib/JSCOptions.cpp:
2855         (jsc_options_foreach):
2856
2857 2019-03-27  Saam Barati  <sbarati@apple.com>
2858
2859         validateOSREntryValue with Int52 should box the value being checked into double format
2860         https://bugs.webkit.org/show_bug.cgi?id=196313
2861         <rdar://problem/49306703>
2862
2863         Reviewed by Yusuke Suzuki.
2864
2865         * dfg/DFGOSREntry.cpp:
2866         (JSC::DFG::prepareOSREntry):
2867         * ftl/FTLLowerDFGToB3.cpp:
2868         (JSC::FTL::DFG::LowerDFGToB3::validateAIState):
2869
2870 2019-03-27  Yusuke Suzuki  <ysuzuki@apple.com>
2871
2872         [JSC] Owner of watchpoints should validate at GC finalizing phase
2873         https://bugs.webkit.org/show_bug.cgi?id=195827
2874
2875         Reviewed by Filip Pizlo.
2876
2877         This patch fixes JSC's watchpoint liveness issue by the following two policies.
2878
2879         1. Watchpoint should have owner cell, and "fire" operation should be gaurded with owner cell's isLive check.
2880
2881         Watchpoints should hold its owner cell, and fire procedure should be guarded by `owner->isLive()`.
2882         When the owner cell is destroyed, these watchpoints are destroyed too. But this destruction can
2883         be delayed due to incremental sweeper. So the following condition can happen.
2884
2885         When we have a watchpoint like the following.
2886
2887             class XXXWatchpoint {
2888                 ObjectPropertyCondition m_key;
2889                 JSCell* m_owner;
2890             };
2891
2892         Both m_key's cell and m_owner is now unreachable from the root. So eventually, m_owner cell's destructor
2893         is called and this watchpoint will be destroyed. But before that, m_key's cell can be destroyed. And this
2894         watchpoint's fire procedure can be called since m_owner's destructor is not called yet. In this situation,
2895         we encounter the destroyed cell held in m_key. This problem can be avoided if we guard fire procedure with
2896         `m_owner->isLive()`. Until the owner cell is destroyed, this guard avoids "fire" procedure execution. And
2897         once the destructor of m_owner is called, this watchpoint will be destroyed too.
2898
2899         2. Watchpoint liveness should be maintained by owner cell's unconditional finalizer
2900
2901         Watchpoints often hold weak references to the other cell (like, m_key in the above example). If we do not
2902         delete watchpoints with dead cells when these weak cells become dead, these watchpoints continue holding dead cells,
2903         and watchpoint's fire operation can use these dead cells accidentally. isLive / isStillLive check for these weak cells
2904         in fire operation is not useful. Because these dead cells can be reused to the other live cells eventually, and this
2905         isLive / isStillLive checks fail to see these cells are live if they are reused. Appropriate way is deleting watchpoints
2906         with dead cells when finalizing GC. In this patch, we do this in unconditional finalizers in owner cells of watchpoints.
2907         We already did this in CodeBlock etc. We add the same thing to StructureRareData which owns watchpoints for toString operations.
2908
2909         * JavaScriptCore.xcodeproj/project.pbxproj:
2910         * Sources.txt:
2911         * bytecode/AdaptiveInferredPropertyValueWatchpointBase.h:
2912         (JSC::AdaptiveInferredPropertyValueWatchpointBase::StructureWatchpoint::StructureWatchpoint): Deleted.
2913         (JSC::AdaptiveInferredPropertyValueWatchpointBase::PropertyWatchpoint::PropertyWatchpoint): Deleted.
2914         * bytecode/CodeBlockJettisoningWatchpoint.h:
2915         (JSC::CodeBlockJettisoningWatchpoint::CodeBlockJettisoningWatchpoint): Deleted.
2916         * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
2917         (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
2918         (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
2919         * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
2920         (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::key const): Deleted.
2921         * bytecode/StructureStubClearingWatchpoint.cpp:
2922         (JSC::StructureStubClearingWatchpoint::fireInternal):
2923         (JSC::WatchpointsOnStructureStubInfo::isValid const):
2924         * bytecode/StructureStubClearingWatchpoint.h:
2925         (JSC::StructureStubClearingWatchpoint::StructureStubClearingWatchpoint): Deleted.
2926         * dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp:
2927         (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::isValid const):
2928         * dfg/DFGAdaptiveInferredPropertyValueWatchpoint.h:
2929         * dfg/DFGAdaptiveStructureWatchpoint.cpp:
2930         (JSC::DFG::AdaptiveStructureWatchpoint::fireInternal):
2931         * dfg/DFGAdaptiveStructureWatchpoint.h:
2932         (JSC::DFG::AdaptiveStructureWatchpoint::key const): Deleted.
2933         * dfg/DFGDesiredWatchpoints.cpp:
2934         (JSC::DFG::ArrayBufferViewWatchpointAdaptor::add):
2935         * heap/Heap.cpp:
2936         (JSC::Heap::finalizeUnconditionalFinalizers):
2937         * llint/LLIntSlowPaths.cpp:
2938         (JSC::LLInt::setupGetByIdPrototypeCache):
2939         * runtime/ArrayBuffer.cpp:
2940         (JSC::ArrayBuffer::notifyIncommingReferencesOfTransfer):
2941         * runtime/ArrayBufferNeuteringWatchpointSet.cpp: Renamed from Source/JavaScriptCore/runtime/ArrayBufferNeuteringWatchpoint.cpp.
2942         (JSC::ArrayBufferNeuteringWatchpointSet::ArrayBufferNeuteringWatchpointSet):
2943         (JSC::ArrayBufferNeuteringWatchpointSet::destroy):
2944         (JSC::ArrayBufferNeuteringWatchpointSet::create):
2945         (JSC::ArrayBufferNeuteringWatchpointSet::createStructure):
2946         (JSC::ArrayBufferNeuteringWatchpointSet::fireAll):
2947         * runtime/ArrayBufferNeuteringWatchpointSet.h: Renamed from Source/JavaScriptCore/runtime/ArrayBufferNeuteringWatchpoint.h.
2948         * runtime/FunctionRareData.h:
2949         * runtime/JSGlobalObject.cpp:
2950         (JSC::JSGlobalObject::init):
2951         (JSC::JSGlobalObject::tryInstallArraySpeciesWatchpoint):
2952         * runtime/ObjectPropertyChangeAdaptiveWatchpoint.h:
2953         (JSC::ObjectPropertyChangeAdaptiveWatchpoint::ObjectPropertyChangeAdaptiveWatchpoint): Deleted.
2954         * runtime/StructureRareData.cpp:
2955         (JSC::StructureRareData::finalizeUnconditionally):
2956         * runtime/StructureRareData.h:
2957         * runtime/VM.cpp:
2958         (JSC::VM::VM):
2959
2960 2019-03-26  Saam Barati  <sbarati@apple.com>
2961
2962         FTL: Emit code to validate AI's state when running the compiled code
2963         https://bugs.webkit.org/show_bug.cgi?id=195924
2964         <rdar://problem/49003422>
2965
2966         Reviewed by Filip Pizlo.
2967
2968         This patch adds code that between the execution of each node that validates
2969         the types that AI proves. This option is too expensive to turn on for our
2970         regression testing, but we think it will be valuable in other types of running
2971         modes, such as when running with a fuzzer.
2972         
2973         This patch also adds options to only probabilistically run this validation
2974         after the execution of each node. As the probability is lowered, there is
2975         less of a perf hit.
2976         
2977         This patch just adds this validation in the FTL. A follow-up patch will land
2978         it in the DFG too: https://bugs.webkit.org/show_bug.cgi?id=196219
2979
2980         * ftl/FTLLowerDFGToB3.cpp:
2981         (JSC::FTL::DFG::LowerDFGToB3::LowerDFGToB3):
2982         (JSC::FTL::DFG::LowerDFGToB3::compileBlock):
2983         (JSC::FTL::DFG::LowerDFGToB3::validateAIState):
2984         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2985         (JSC::FTL::DFG::LowerDFGToB3::lowJSValue):
2986         * runtime/Options.h:
2987
2988 2019-03-26  Tadeu Zagallo  <tzagallo@apple.com>
2989
2990         WebAssembly: Fix f32.min, f64.min and f64.max operations on NaN
2991         https://bugs.webkit.org/show_bug.cgi?id=196217
2992
2993         Reviewed by Saam Barati.
2994
2995         Generalize the fix for f32.max to properly handle NaN by doing an extra GreatherThan
2996         comparison in r243446 to all min and max float operations.
2997
2998         * wasm/WasmAirIRGenerator.cpp:
2999         (JSC::Wasm::AirIRGenerator::addOp<OpType::F32Min>):
3000         (JSC::Wasm::AirIRGenerator::addFloatingPointMinOrMax):
3001         (JSC::Wasm::AirIRGenerator::addOp<OpType::F32Max>):
3002         (JSC::Wasm::AirIRGenerator::addOp<OpType::F64Min>):
3003         (JSC::Wasm::AirIRGenerator::addOp<OpType::F64Max>):
3004         * wasm/wasm.json:
3005
3006 2019-03-26  Andy VanWagoner  <andy@vanwagoner.family>
3007
3008         Intl.DateTimeFormat should obey 2-digit hour
3009         https://bugs.webkit.org/show_bug.cgi?id=195974
3010
3011         Reviewed by Keith Miller.
3012
3013         * runtime/IntlDateTimeFormat.cpp:
3014         (JSC::IntlDateTimeFormat::initializeDateTimeFormat):
3015
3016 2019-03-25  Yusuke Suzuki  <ysuzuki@apple.com>
3017
3018         Heap::isMarked and friends should be instance methods
3019         https://bugs.webkit.org/show_bug.cgi?id=179988
3020
3021         Reviewed by Saam Barati.
3022
3023         Almost all the callers of Heap::isMarked have VM& reference. We should make Heap::isMarked instance function instead of static function
3024         so that we do not need to look up Heap from the cell.
3025
3026         * API/JSAPIWrapperObject.mm:
3027         (JSAPIWrapperObjectHandleOwner::isReachableFromOpaqueRoots):
3028         * API/JSMarkingConstraintPrivate.cpp:
3029         (JSC::isMarked):
3030         * API/glib/JSAPIWrapperObjectGLib.cpp:
3031         (JSAPIWrapperObjectHandleOwner::isReachableFromOpaqueRoots):
3032         * builtins/BuiltinExecutables.cpp:
3033         (JSC::BuiltinExecutables::finalizeUnconditionally):
3034         * bytecode/AccessCase.cpp:
3035         (JSC::AccessCase::visitWeak const):
3036         (JSC::AccessCase::propagateTransitions const):
3037         * bytecode/CallLinkInfo.cpp:
3038         (JSC::CallLinkInfo::visitWeak):
3039         * bytecode/CallLinkStatus.cpp:
3040         (JSC::CallLinkStatus::finalize):
3041         * bytecode/CallLinkStatus.h:
3042         * bytecode/CallVariant.cpp:
3043         (JSC::CallVariant::finalize):
3044         * bytecode/CallVariant.h:
3045         * bytecode/CodeBlock.cpp:
3046         (JSC::CodeBlock::shouldJettisonDueToWeakReference):
3047         (JSC::CodeBlock::shouldJettisonDueToOldAge):
3048         (JSC::shouldMarkTransition):
3049         (JSC::CodeBlock::propagateTransitions):
3050         (JSC::CodeBlock::determineLiveness):
3051         (JSC::CodeBlock::finalizeLLIntInlineCaches):
3052         (JSC::CodeBlock::finalizeUnconditionally):
3053         (JSC::CodeBlock::jettison):
3054         * bytecode/CodeBlock.h:
3055         * bytecode/ExecutableToCodeBlockEdge.cpp:
3056         (JSC::ExecutableToCodeBlockEdge::visitChildren):
3057         (JSC::ExecutableToCodeBlockEdge::finalizeUnconditionally):
3058         (JSC::ExecutableToCodeBlockEdge::runConstraint):
3059         * bytecode/GetByIdStatus.cpp:
3060         (JSC::GetByIdStatus::finalize):
3061         * bytecode/GetByIdStatus.h:
3062         * bytecode/GetByIdVariant.cpp:
3063         (JSC::GetByIdVariant::finalize):
3064         * bytecode/GetByIdVariant.h:
3065         * bytecode/InByIdStatus.cpp:
3066         (JSC::InByIdStatus::finalize):
3067         * bytecode/InByIdStatus.h:
3068         * bytecode/InByIdVariant.cpp:
3069         (JSC::InByIdVariant::finalize):
3070         * bytecode/InByIdVariant.h:
3071         * bytecode/ObjectPropertyCondition.cpp:
3072         (JSC::ObjectPropertyCondition::isStillLive const):
3073         * bytecode/ObjectPropertyCondition.h:
3074         * bytecode/ObjectPropertyConditionSet.cpp:
3075         (JSC::ObjectPropertyConditionSet::areStillLive const):
3076         * bytecode/ObjectPropertyConditionSet.h:
3077         * bytecode/PolymorphicAccess.cpp:
3078         (JSC::PolymorphicAccess::visitWeak const):
3079         * bytecode/PropertyCondition.cpp:
3080         (JSC::PropertyCondition::isStillLive const):
3081         * bytecode/PropertyCondition.h:
3082         * bytecode/PutByIdStatus.cpp:
3083         (JSC::PutByIdStatus::finalize):
3084         * bytecode/PutByIdStatus.h:
3085         * bytecode/PutByIdVariant.cpp:
3086         (JSC::PutByIdVariant::finalize):
3087         * bytecode/PutByIdVariant.h:
3088         * bytecode/RecordedStatuses.cpp:
3089         (JSC::RecordedStatuses::finalizeWithoutDeleting):
3090         (JSC::RecordedStatuses::finalize):
3091         * bytecode/RecordedStatuses.h:
3092         * bytecode/StructureSet.cpp:
3093         (JSC::StructureSet::isStillAlive const):
3094         * bytecode/StructureSet.h:
3095         * bytecode/StructureStubInfo.cpp:
3096         (JSC::StructureStubInfo::visitWeakReferences):
3097         * dfg/DFGPlan.cpp:
3098         (JSC::DFG::Plan::finalizeInGC):
3099         (JSC::DFG::Plan::isKnownToBeLiveDuringGC):
3100         * heap/GCIncomingRefCounted.h:
3101         * heap/GCIncomingRefCountedInlines.h:
3102         (JSC::GCIncomingRefCounted<T>::filterIncomingReferences):
3103         * heap/GCIncomingRefCountedSet.h:
3104         * heap/GCIncomingRefCountedSetInlines.h:
3105         (JSC::GCIncomingRefCountedSet<T>::lastChanceToFinalize):
3106         (JSC::GCIncomingRefCountedSet<T>::sweep):
3107         (JSC::GCIncomingRefCountedSet<T>::removeAll): Deleted.
3108         (JSC::GCIncomingRefCountedSet<T>::removeDead): Deleted.
3109         * heap/Heap.cpp:
3110         (JSC::Heap::addToRememberedSet):
3111         (JSC::Heap::runEndPhase):
3112         (JSC::Heap::sweepArrayBuffers):
3113         (JSC::Heap::addCoreConstraints):
3114         * heap/Heap.h:
3115         * heap/HeapInlines.h:
3116         (JSC::Heap::isMarked):
3117         * heap/HeapSnapshotBuilder.cpp:
3118         (JSC::HeapSnapshotBuilder::appendNode):
3119         * heap/SlotVisitor.cpp:
3120         (JSC::SlotVisitor::appendToMarkStack):
3121         (JSC::SlotVisitor::visitChildren):
3122         * jit/PolymorphicCallStubRoutine.cpp:
3123         (JSC::PolymorphicCallStubRoutine::visitWeak):
3124         * runtime/ErrorInstance.cpp:
3125         (JSC::ErrorInstance::finalizeUnconditionally):
3126         * runtime/InferredValueInlines.h:
3127         (JSC::InferredValue::finalizeUnconditionally):
3128         * runtime/StackFrame.h:
3129         (JSC::StackFrame::isMarked const):
3130         * runtime/Structure.cpp:
3131         (JSC::Structure::isCheapDuringGC):
3132         (JSC::Structure::markIfCheap):
3133         * runtime/Structure.h:
3134         * runtime/TypeProfiler.cpp:
3135         (JSC::TypeProfiler::invalidateTypeSetCache):
3136         * runtime/TypeProfiler.h:
3137         * runtime/TypeSet.cpp:
3138         (JSC::TypeSet::invalidateCache):
3139         * runtime/TypeSet.h:
3140         * runtime/WeakMapImpl.cpp:
3141         (JSC::WeakMapImpl<WeakMapBucket<WeakMapBucketDataKeyValue>>::visitOutputConstraints):
3142         * runtime/WeakMapImplInlines.h:
3143         (JSC::WeakMapImpl<WeakMapBucket>::finalizeUnconditionally):
3144
3145 2019-03-25  Keith Miller  <keith_miller@apple.com>
3146
3147         ASSERTION FAILED: m_op == CompareStrictEq in JSC::DFG::Node::convertToCompareEqPtr(JSC::DFG::FrozenValue *, JSC::DFG::Edge)
3148         https://bugs.webkit.org/show_bug.cgi?id=196176
3149
3150         Reviewed by Saam Barati.
3151
3152         convertToCompareEqPtr should allow for either CompareStrictEq or
3153         the SameValue DFG node. This fixes the old assertion that only
3154         allowed CompareStrictEq.
3155
3156         * dfg/DFGNode.h:
3157         (JSC::DFG::Node::convertToCompareEqPtr):
3158
3159 2019-03-25  Tadeu Zagallo  <tzagallo@apple.com>
3160
3161         WebAssembly: f32.max with NaN generates incorrect result
3162         https://bugs.webkit.org/show_bug.cgi?id=175691
3163         <rdar://problem/33952228>
3164
3165         Reviewed by Saam Barati.
3166
3167         Fix the B3 and Air compilation for f32.max. In order to handle the NaN
3168         case, we need an extra GreaterThan comparison on top of the existing
3169         Equal and LessThan ones.
3170
3171         * wasm/WasmAirIRGenerator.cpp:
3172         (JSC::Wasm::AirIRGenerator::addOp<OpType::F32Max>):
3173         * wasm/wasm.json:
3174
3175 2019-03-25  Yusuke Suzuki  <ysuzuki@apple.com>
3176
3177         Unreviewed, speculative fix for CLoop build on CPU(UNKNOWN)
3178         https://bugs.webkit.org/show_bug.cgi?id=195982
3179
3180         * jit/ExecutableAllocator.h:
3181         (JSC::ExecutableAllocator::initializeUnderlyingAllocator):
3182
3183 2019-03-25  Gyuyoung Kim  <gyuyoung.kim@webkit.org>
3184
3185         Remove NavigatorContentUtils in WebCore/Modules
3186         https://bugs.webkit.org/show_bug.cgi?id=196070
3187
3188         Reviewed by Alex Christensen.
3189
3190         NavigatorContentUtils was to support the custom scheme spec [1].
3191         However, in WebKit side, no port has supported the feature in
3192         WebKit layer after EFL port was removed. So there has been the
3193         only IDL implementation of the NavigatorContentUtils in WebCore.
3194         So we don't need to keep the implementation in WebCore anymore.
3195
3196         [1] https://html.spec.whatwg.org/multipage/system-state.html#custom-handlers
3197
3198         * Configurations/FeatureDefines.xcconfig:
3199
3200 2019-03-23  Mark Lam  <mark.lam@apple.com>
3201
3202         Rolling out r243032 and r243071 because the fix is incorrect.
3203         https://bugs.webkit.org/show_bug.cgi?id=195892
3204         <rdar://problem/48981239>
3205
3206         Not reviewed.
3207
3208         The fix is incorrect: it relies on being able to determine liveness of an object
3209         in an ObjectPropertyCondition based on the state of the object's MarkedBit.
3210         However, there's no guarantee that GC has run and that the MarkedBit is already
3211         set even if the object is live.  As a result, we may not re-install adaptive
3212         watchpoints based on presumed dead objects which are actually live.
3213
3214         I'm rolling this out, and will implement a more comprehensive fix to handle
3215         watchpoint liveness later.
3216
3217         * bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp:
3218         (JSC::AdaptiveInferredPropertyValueWatchpointBase::fire):
3219         * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
3220         (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
3221         * bytecode/ObjectPropertyCondition.cpp:
3222         (JSC::ObjectPropertyCondition::dumpInContext const):
3223         * bytecode/StructureStubClearingWatchpoint.cpp:
3224         (JSC::StructureStubClearingWatchpoint::fireInternal):
3225         * dfg/DFGAdaptiveStructureWatchpoint.cpp:
3226         (JSC::DFG::AdaptiveStructureWatchpoint::fireInternal):
3227         * runtime/StructureRareData.cpp:
3228         (JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal):
3229
3230 2019-03-23  Keith Miller  <keith_miller@apple.com>
3231
3232         Refactor clz/ctz and fix getLSBSet.
3233         https://bugs.webkit.org/show_bug.cgi?id=196162
3234
3235         Reviewed by Saam Barati.
3236
3237         Refactor references of clz32/64 and ctz32 to use clz and ctz,
3238         respectively.
3239
3240         * dfg/DFGAbstractInterpreterInlines.h:
3241         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3242         * dfg/DFGOperations.cpp:
3243         * runtime/JSBigInt.cpp:
3244         (JSC::JSBigInt::digitDiv):
3245         (JSC::JSBigInt::absoluteDivWithBigIntDivisor):
3246         (JSC::JSBigInt::calculateMaximumCharactersRequired):
3247         (JSC::JSBigInt::toStringBasePowerOfTwo):
3248         (JSC::JSBigInt::compareToDouble):
3249         * runtime/MathObject.cpp:
3250         (JSC::mathProtoFuncClz32):
3251
3252 2019-03-23  Yusuke Suzuki  <ysuzuki@apple.com>
3253
3254         [JSC] Shrink sizeof(RegExp)
3255         https://bugs.webkit.org/show_bug.cgi?id=196133
3256
3257         Reviewed by Mark Lam.
3258
3259         Some applications have many RegExp cells. But RegExp cells are very large (144B).
3260         This patch reduces the size from 144B to 48B by,
3261
3262         1. Allocate Yarr::YarrCodeBlock in non-GC heap. We can avoid this allocation if JIT is disabled.
3263         2. m_captureGroupNames and m_namedGroupToParenIndex are moved to RareData. They are only used when RegExp has named capture groups.
3264
3265         * runtime/RegExp.cpp:
3266         (JSC::RegExp::finishCreation):
3267         (JSC::RegExp::estimatedSize):
3268         (JSC::RegExp::compile):
3269         (JSC::RegExp::matchConcurrently):
3270         (JSC::RegExp::compileMatchOnly):
3271         (JSC::RegExp::deleteCode):
3272         (JSC::RegExp::printTraceData):
3273         * runtime/RegExp.h:
3274         * runtime/RegExpInlines.h:
3275         (JSC::RegExp::hasCodeFor):
3276         (JSC::RegExp::matchInline):
3277         (JSC::RegExp::hasMatchOnlyCodeFor):
3278
3279 2019-03-22  Keith Rollin  <krollin@apple.com>
3280
3281         Enable ThinLTO support in Production builds
3282         https://bugs.webkit.org/show_bug.cgi?id=190758
3283         <rdar://problem/45413233>
3284
3285         Reviewed by Daniel Bates.
3286
3287         Tweak JavaScriptCore's Base.xcconfig to be more in-line with other
3288         .xcconfig files with regards to LTO settings. However, don't actually
3289         enable LTO for JavaScriptCore. LTO is not enabled for JavaScriptCore
3290         due to <rdar://problem/24543547>.
3291
3292         * Configurations/Base.xcconfig:
3293
3294 2019-03-22  Mark Lam  <mark.lam@apple.com>
3295
3296         Placate exception check validation in genericTypedArrayViewProtoFuncLastIndexOf().
3297         https://bugs.webkit.org/show_bug.cgi?id=196154
3298         <rdar://problem/49145307>
3299
3300         Reviewed by Filip Pizlo.
3301
3302         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
3303         (JSC::genericTypedArrayViewProtoFuncLastIndexOf):
3304
3305 2019-03-22  Mark Lam  <mark.lam@apple.com>
3306
3307         Placate exception check validation in constructJSWebAssemblyLinkError().
3308         https://bugs.webkit.org/show_bug.cgi?id=196152
3309         <rdar://problem/49145257>
3310
3311         Reviewed by Michael Saboff.
3312
3313         * wasm/js/WebAssemblyLinkErrorConstructor.cpp:
3314         (JSC::constructJSWebAssemblyLinkError):
3315
3316 2019-03-22  Timothy Hatcher  <timothy@apple.com>
3317
3318         Change macosx() to macos() in WK_API... and JSC_API... macros.
3319         https://bugs.webkit.org/show_bug.cgi?id=196106
3320
3321         Reviewed by Brian Burg.
3322
3323         * API/JSBasePrivate.h:
3324         * API/JSContext.h: