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