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