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