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