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