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