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