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