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