5388461c95d1c0fd41dc90d70a9e1002a2e8fe76
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2015-10-21  Saam barati  <sbarati@apple.com>
2
3         C calls in PolymorphicAccess shouldn't assume that the top of the stack looks like a JSC JIT frame and enable *ByIdFlush in FTL
4         https://bugs.webkit.org/show_bug.cgi?id=125711
5
6         Reviewed by Filip Pizlo.
7
8         This patch ensures that anytime we need to make a C call inside
9         PolymorphicAccess, we ensure there is enough space on the stack to do so.
10
11         This patch also enables GetByIdFlush/PutByIdFlush inside the FTL.
12         Because PolymorphicAccess now spills the necessary registers
13         before making a JS/C call, any registers that LLVM report as
14         being in use for the patchpoint will be spilled before making
15         a call by PolymorphicAccess.
16
17         * bytecode/PolymorphicAccess.cpp:
18         (JSC::AccessGenerationState::restoreScratch):
19         (JSC::AccessGenerationState::succeed):
20         (JSC::AccessGenerationState::calculateLiveRegistersForCallAndExceptionHandling):
21         (JSC::AccessCase::generate):
22         (JSC::PolymorphicAccess::regenerate):
23         * ftl/FTLCapabilities.cpp:
24         (JSC::FTL::canCompile):
25         * ftl/FTLLowerDFGToLLVM.cpp:
26         (JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
27         (JSC::FTL::DFG::LowerDFGToLLVM::compileGetById):
28         (JSC::FTL::DFG::LowerDFGToLLVM::emitStoreBarrier):
29         * jit/AssemblyHelpers.h:
30         (JSC::AssemblyHelpers::emitTypeOf):
31         (JSC::AssemblyHelpers::makeSpaceOnStackForCCall):
32         (JSC::AssemblyHelpers::reclaimSpaceOnStackForCCall):
33         * jit/RegisterSet.cpp:
34         (JSC::RegisterSet::webAssemblyCalleeSaveRegisters):
35         (JSC::RegisterSet::registersToNotSaveForJSCall):
36         (JSC::RegisterSet::registersToNotSaveForCCall):
37         (JSC::RegisterSet::allGPRs):
38         (JSC::RegisterSet::registersToNotSaveForCall): Deleted.
39         * jit/RegisterSet.h:
40         (JSC::RegisterSet::set):
41         * jit/ScratchRegisterAllocator.cpp:
42         (JSC::ScratchRegisterAllocator::allocateScratchGPR):
43         (JSC::ScratchRegisterAllocator::allocateScratchFPR):
44         (JSC::ScratchRegisterAllocator::preserveReusedRegistersByPushing):
45         (JSC::ScratchRegisterAllocator::restoreReusedRegistersByPopping):
46         These methods now take an extra parameter indicating if they
47         should create space for a C call at the top of the stack if
48         there are any reused registers to spill.
49
50         (JSC::ScratchRegisterAllocator::usedRegistersForCall):
51         * jit/ScratchRegisterAllocator.h:
52         (JSC::ScratchRegisterAllocator::usedRegisters):
53
54 2015-10-21  Joseph Pecoraro  <pecoraro@apple.com>
55
56         Web Inspector: Array previews with Symbol objects have too few preview values
57         https://bugs.webkit.org/show_bug.cgi?id=150404
58
59         Reviewed by Timothy Hatcher.
60
61         * inspector/InjectedScriptSource.js:
62         (InjectedScript.RemoteObject.prototype._appendPropertyPreviews):
63         We should be continuing inside this loop not returning.
64
65 2015-10-21  Filip Pizlo  <fpizlo@apple.com>
66
67         Failures in PutStackSinkingPhase should be less severe
68         https://bugs.webkit.org/show_bug.cgi?id=150400
69
70         Reviewed by Geoffrey Garen.
71
72         Make the PutStackSinkingPhase abort instead of asserting. To test that it's OK to not have
73         PutStackSinkingPhase run, this adds a test mode where we run without PutStackSinkingPhase.
74
75         * dfg/DFGPlan.cpp: Make it possible to not run PutStackSinkingPhase for tests.
76         (JSC::DFG::Plan::compileInThreadImpl):
77         * dfg/DFGPutStackSinkingPhase.cpp: PutStackSinkingPhase should abort instead of asserting, except when validation is enabled.
78         * runtime/Options.h: Add an option for disabling PutStackSinkingPhase.
79
80 2015-10-21  Saam barati  <sbarati@apple.com>
81
82         The FTL should place the CallSiteIndex on the call frame for JS calls when it fills in the patchpoint
83         https://bugs.webkit.org/show_bug.cgi?id=150104
84
85         Reviewed by Filip Pizlo.
86
87         We lower JS Calls to patchpoints in LLVM. LLVM may decide to duplicate
88         these patchpoints (or remove them). We eagerly store the CallSiteIndex on the 
89         call frame when lowering DFG to LLVM. But, because the patchpoint we lower to may
90         be duplicated, we really don't know the unique CallSiteIndex until we've
91         actually seen the resulting patchpoints after LLVM has completed its transformations.
92         To solve this, we now store the unique CallSiteIndex on the call frame header 
93         when generating code to fill into the patchpoint.
94
95         * ftl/FTLCompile.cpp:
96         (JSC::FTL::mmAllocateDataSection):
97         * ftl/FTLJSCall.cpp:
98         (JSC::FTL::JSCall::JSCall):
99         (JSC::FTL::JSCall::emit):
100         * ftl/FTLJSCall.h:
101         (JSC::FTL::JSCall::stackmapID):
102         * ftl/FTLJSCallBase.cpp:
103         (JSC::FTL::JSCallBase::JSCallBase):
104         (JSC::FTL::JSCallBase::emit):
105         (JSC::FTL::JSCallBase::link):
106         * ftl/FTLJSCallBase.h:
107         * ftl/FTLJSCallVarargs.cpp:
108         (JSC::FTL::JSCallVarargs::JSCallVarargs):
109         (JSC::FTL::JSCallVarargs::numSpillSlotsNeeded):
110         (JSC::FTL::JSCallVarargs::emit):
111         * ftl/FTLJSCallVarargs.h:
112         (JSC::FTL::JSCallVarargs::node):
113         (JSC::FTL::JSCallVarargs::stackmapID):
114         * ftl/FTLJSTailCall.cpp:
115         (JSC::FTL::JSTailCall::JSTailCall):
116         (JSC::FTL::m_instructionOffset):
117         (JSC::FTL::JSTailCall::emit):
118         * ftl/FTLLowerDFGToLLVM.cpp:
119         (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstruct):
120         (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstructVarargs):
121         (JSC::FTL::DFG::LowerDFGToLLVM::callPreflight):
122         (JSC::FTL::DFG::LowerDFGToLLVM::codeOriginDescriptionOfCallSite):
123         (JSC::FTL::DFG::LowerDFGToLLVM::callCheck):
124
125 2015-10-21  Geoffrey Garen  <ggaren@apple.com>
126
127         Date creation should share a little code
128         https://bugs.webkit.org/show_bug.cgi?id=150399
129
130         Reviewed by Filip Pizlo.
131
132         I want to fix a bug in this code, but I don't want to fix it in two
133         different places. (See https://bugs.webkit.org/show_bug.cgi?id=150386.)
134
135         * runtime/DateConstructor.cpp:
136         (JSC::DateConstructor::getOwnPropertySlot):
137         (JSC::milliseconds): Factored out a shared helper function. If you look
138         closely, you'll see that one copy of this code previously checked isfinite
139         while the other checked isnan. isnan returning nan was obviously a no-op,
140         so I removed it. isfinite, it turns out, is also a no-op -- but less
141         obviously so, so I kept it for now.
142
143         (JSC::constructDate):
144         (JSC::dateUTC): Use the helper function.
145
146 2015-10-21  Guillaume Emont  <guijemont@igalia.com>
147
148         llint: align stack pointer on mips too
149
150         [MIPS] LLInt: align stack pointer on MIPS too
151         https://bugs.webkit.org/show_bug.cgi?id=150380
152
153         Reviewed by Michael Saboff.
154
155         * llint/LowLevelInterpreter32_64.asm:
156
157 2015-10-20  Mark Lam  <mark.lam@apple.com>
158
159         YarrPatternConstructor::containsCapturingTerms() should not assume that its terms.size() is greater than 0.
160         https://bugs.webkit.org/show_bug.cgi?id=150372
161
162         Reviewed by Geoffrey Garen.
163
164         * yarr/YarrPattern.cpp:
165         (JSC::Yarr::CharacterClassConstructor::CharacterClassConstructor):
166         (JSC::Yarr::YarrPatternConstructor::optimizeBOL):
167         (JSC::Yarr::YarrPatternConstructor::containsCapturingTerms):
168         (JSC::Yarr::YarrPatternConstructor::optimizeDotStarWrappedExpressions):
169
170 2015-10-20  Michael Saboff  <msaboff@apple.com>
171
172         REGRESSION (r191175): OSR Exit from an inlined tail callee trashes callee save registers
173         https://bugs.webkit.org/show_bug.cgi?id=150336
174
175         Reviewed by Mark Lam.
176
177         During OSR exit, we need to restore and transform the active stack into what the baseline
178         JIT expects.  Inlined call frames become true call frames.  When we reify an inlined call
179         frame and it is a tail call which we will be continuing from, we need to restore the tag
180         constant callee save registers with what was saved by the outermost caller.
181
182         Re-enabled tail calls and restored tests for tail calls.
183
184         * dfg/DFGOSRExitCompilerCommon.cpp:
185         (JSC::DFG::reifyInlinedCallFrames): Select whether or not we use the callee save tag register
186         contents or what was saved by the inlining caller when populating an inlined callee's
187         callee save registers.
188         * jit/AssemblyHelpers.h:
189         (JSC::AssemblyHelpers::emitSaveCalleeSavesFor): This function no longer needs a stack offset.
190         (JSC::AssemblyHelpers::emitSaveOrCopyCalleeSavesFor): New helper.
191         * runtime/Options.h: Turned tail calls back on.
192         * tests/es6.yaml:
193         * tests/stress/dfg-tail-calls.js:
194         (nonInlinedTailCall.callee):
195         * tests/stress/mutual-tail-call-no-stack-overflow.js:
196         (shouldThrow):
197         * tests/stress/tail-call-in-inline-cache.js:
198         (tail):
199         * tests/stress/tail-call-no-stack-overflow.js:
200         (shouldThrow):
201         * tests/stress/tail-call-recognize.js:
202         (callerMustBeRun):
203         * tests/stress/tail-call-varargs-no-stack-overflow.js:
204         (shouldThrow):
205
206 2015-10-20  Joseph Pecoraro  <pecoraro@apple.com>
207
208         Web Inspector: JavaScriptCore should parse sourceURL and sourceMappingURL directives
209         https://bugs.webkit.org/show_bug.cgi?id=150096
210
211         Reviewed by Geoffrey Garen.
212
213         * inspector/ContentSearchUtilities.cpp:
214         (Inspector::ContentSearchUtilities::scriptCommentPattern): Deleted.
215         (Inspector::ContentSearchUtilities::findScriptSourceURL): Deleted.
216         (Inspector::ContentSearchUtilities::findScriptSourceMapURL): Deleted.
217         * inspector/ContentSearchUtilities.h:
218         No longer need to search script content.
219
220         * inspector/ScriptDebugServer.cpp:
221         (Inspector::ScriptDebugServer::dispatchDidParseSource):
222         Carry over the sourceURL and sourceMappingURL from the SourceProvider.
223
224         * inspector/agents/InspectorDebuggerAgent.cpp:
225         (Inspector::InspectorDebuggerAgent::sourceMapURLForScript):
226         (Inspector::InspectorDebuggerAgent::didParseSource):
227         No longer do content searching.
228
229         * parser/Lexer.cpp:
230         (JSC::Lexer<T>::setCode):
231         (JSC::Lexer<T>::skipWhitespace):
232         (JSC::Lexer<T>::parseCommentDirective):
233         (JSC::Lexer<T>::parseCommentDirectiveValue):
234         (JSC::Lexer<T>::consume):
235         (JSC::Lexer<T>::lex):
236         * parser/Lexer.h:
237         (JSC::Lexer::sourceURL):
238         (JSC::Lexer::sourceMappingURL):
239         (JSC::Lexer::sourceProvider): Deleted.
240         Give lexer the ability to detect script comment directives.
241         This just consumes characters in single line comments and
242         ultimately sets the sourceURL or sourceMappingURL found.
243
244         * parser/Parser.h:
245         (JSC::Parser<LexerType>::parse):
246         * parser/SourceProvider.h:
247         (JSC::SourceProvider::url):
248         (JSC::SourceProvider::sourceURL):
249         (JSC::SourceProvider::sourceMappingURL):
250         (JSC::SourceProvider::setSourceURL):
251         (JSC::SourceProvider::setSourceMappingURL):
252         After parsing a script, update the Source Provider with the
253         value of directives that may have been found in the script.
254
255 2015-10-20  Saam barati  <sbarati@apple.com>
256
257         GCAwareJITStubRoutineWithExceptionHandler has a stale CodeBlock pointer in its destructor
258         https://bugs.webkit.org/show_bug.cgi?id=150351
259
260         Reviewed by Mark Lam.
261
262         We may regenerate many GCAwareJITStubRoutineWithExceptionHandler stubs per one PolymorphicAccess.
263         Only the last GCAwareJITStubRoutineWithExceptionHandler stub that was generated will get the CodeBlock's aboutToDie()
264         notification. All other GCAwareJITStubRoutineWithExceptionHandler stubs will still be holding a stale CodeBlock pointer
265         that they will use in their destructor. The solution is to have GCAwareJITStubRoutineWithExceptionHandler remove its
266         exception handler in observeZeroRefCount() instead of its destructor. observeZeroRefCount() will run when a PolymorphicAccess
267         replaces its m_stubRoutine.
268
269         * jit/GCAwareJITStubRoutine.cpp:
270         (JSC::GCAwareJITStubRoutineWithExceptionHandler::aboutToDie):
271         (JSC::GCAwareJITStubRoutineWithExceptionHandler::observeZeroRefCount):
272         (JSC::createJITStubRoutine):
273         (JSC::GCAwareJITStubRoutineWithExceptionHandler::~GCAwareJITStubRoutineWithExceptionHandler): Deleted.
274         * jit/GCAwareJITStubRoutine.h:
275
276 >>>>>>> .r191351
277 2015-10-20  Tim Horton  <timothy_horton@apple.com>
278
279         Try to fix the build by disabling MAC_GESTURE_EVENTS on 10.9 and 10.10
280
281         * Configurations/FeatureDefines.xcconfig:
282
283 2015-10-20  Xabier Rodriguez Calvar  <calvaris@igalia.com>
284
285         [Streams API] Rework some readable stream internals that can be common to writable streams
286         https://bugs.webkit.org/show_bug.cgi?id=150133
287
288         Reviewed by Darin Adler.
289
290         * runtime/CommonIdentifiers.h:
291         * runtime/JSGlobalObject.cpp:
292         (JSC::JSGlobalObject::init): Added RangeError also as native functions.
293
294 2015-10-20  Yoav Weiss  <yoav@yoav.ws>
295
296         Rename the PICTURE_SIZES flag to CURRENTSRC
297         https://bugs.webkit.org/show_bug.cgi?id=150275
298
299         Reviewed by Dean Jackson.
300
301         * Configurations/FeatureDefines.xcconfig:
302
303 2015-10-19  Saam barati  <sbarati@apple.com>
304
305         FTL should generate a unique OSR exit for each duplicated OSR exit stackmap intrinsic.
306         https://bugs.webkit.org/show_bug.cgi?id=149970
307
308         Reviewed by Filip Pizlo.
309
310         When we lower DFG to LLVM, we generate a stackmap intrnsic for OSR 
311         exits. We also recorded the OSR exit inside FTL::JITCode during lowering.
312         This stackmap intrinsic may be duplicated or even removed by LLVM.
313         When the stackmap intrinsic is duplicated, we used to generate just
314         a single OSR exit data structure. Then, when we compiled an OSR exit, we 
315         would look for the first record in the record list that had the same stackmap ID
316         as what the OSR exit data structure had. We did this even when the OSR exit
317         stackmap intrinsic was duplicated. This would lead us to grab the wrong FTL::StackMaps::Record.
318
319         Now, each OSR exit knows exactly which FTL::StackMaps::Record it corresponds to.
320         We accomplish this by having an OSRExitDescriptor that is recorded during
321         lowering. Each descriptor may be referenced my zero, one, or more OSRExits.
322         Now, no more than one stackmap intrinsic corresponds to the same index inside 
323         JITCode's OSRExit Vector. Also, each OSRExit jump now jumps to a code location.
324
325         * ftl/FTLCompile.cpp:
326         (JSC::FTL::mmAllocateDataSection):
327         * ftl/FTLJITCode.cpp:
328         (JSC::FTL::JITCode::validateReferences):
329         (JSC::FTL::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite):
330         * ftl/FTLJITCode.h:
331         * ftl/FTLJITFinalizer.cpp:
332         (JSC::FTL::JITFinalizer::finalizeFunction):
333         * ftl/FTLLowerDFGToLLVM.cpp:
334         (JSC::FTL::DFG::LowerDFGToLLVM::compileInvalidationPoint):
335         (JSC::FTL::DFG::LowerDFGToLLVM::compileIsUndefined):
336         (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
337         (JSC::FTL::DFG::LowerDFGToLLVM::emitOSRExitCall):
338         (JSC::FTL::DFG::LowerDFGToLLVM::buildExitArguments):
339         (JSC::FTL::DFG::LowerDFGToLLVM::callStackmap):
340         * ftl/FTLOSRExit.cpp:
341         (JSC::FTL::OSRExitDescriptor::OSRExitDescriptor):
342         (JSC::FTL::OSRExitDescriptor::validateReferences):
343         (JSC::FTL::OSRExit::OSRExit):
344         (JSC::FTL::OSRExit::codeLocationForRepatch):
345         (JSC::FTL::OSRExit::validateReferences): Deleted.
346         * ftl/FTLOSRExit.h:
347         (JSC::FTL::OSRExit::considerAddingAsFrequentExitSite):
348         * ftl/FTLOSRExitCompilationInfo.h:
349         (JSC::FTL::OSRExitCompilationInfo::OSRExitCompilationInfo):
350         * ftl/FTLOSRExitCompiler.cpp:
351         (JSC::FTL::compileStub):
352         (JSC::FTL::compileFTLOSRExit):
353         * ftl/FTLStackMaps.cpp:
354         (JSC::FTL::StackMaps::computeRecordMap):
355         * ftl/FTLStackMaps.h:
356
357 2015-10-16  Brian Burg  <bburg@apple.com>
358
359         Unify handling of JavaScriptCore scripts that are used in WebCore
360         https://bugs.webkit.org/show_bug.cgi?id=150245
361
362         Reviewed by Alex Christensen.
363
364         Move all standalone JavaScriptCore scripts that are used by WebCore into the
365         JavaScriptCore/Scripts directory. Use JavaScriptCore_SCRIPTS_DIR to refer
366         to the path for these scripts.
367
368         * DerivedSources.make:
369
370             Define and use JavaScriptCore_SCRIPTS_DIR.
371
372         * JavaScriptCore.xcodeproj/project.pbxproj:
373
374             Make a new group in the Xcode project and clean up references.
375
376         * PlatformWin.cmake:
377
378             For Windows, copy these scripts over to ForwardingHeaders/Scripts since they
379             cannot be used directly from JAVASCRIPTCORE_DIR in AppleWin builds. Do the same
380             thing for both Windows variants to be consistent about it.
381
382         * Scripts/cssmin.py: Renamed from Source/JavaScriptCore/inspector/scripts/cssmin.py.
383         * Scripts/generate-combined-inspector-json.py: Renamed from Source/JavaScriptCore/inspector/scripts/generate-combined-inspector-json.py.
384         * Scripts/generate-js-builtins: Renamed from Source/JavaScriptCore/generate-js-builtins.
385         * Scripts/inline-and-minify-stylesheets-and-scripts.py: Renamed from Source/JavaScriptCore/inspector/scripts/inline-and-minify-stylesheets-and-scripts.py.
386         * Scripts/jsmin.py: Renamed from Source/JavaScriptCore/inspector/scripts/jsmin.py.
387         * Scripts/xxd.pl: Renamed from Source/JavaScriptCore/inspector/scripts/xxd.pl.
388
389 2015-10-19  Tim Horton  <timothy_horton@apple.com>
390
391         Try to fix the iOS build
392
393         * Configurations/FeatureDefines.xcconfig:
394
395 2015-10-17  Keith Miller  <keith_miller@apple.com>
396
397         Add regression tests for TypedArray.prototype functions' error messages.
398         https://bugs.webkit.org/show_bug.cgi?id=150288
399
400         Reviewed by Darin Adler.
401
402         Fix a typo in the text passed by TypedArrray.prototype.filter type error message.
403         Add tests that check the actual error message text for all the TypeArray.prototype
404         functions that throw.
405
406         * builtins/TypedArray.prototype.js:
407         (filter):
408         * tests/stress/typedarray-every.js:
409         * tests/stress/typedarray-filter.js:
410         * tests/stress/typedarray-find.js:
411         * tests/stress/typedarray-findIndex.js:
412         * tests/stress/typedarray-forEach.js:
413         * tests/stress/typedarray-map.js:
414         * tests/stress/typedarray-reduce.js:
415         * tests/stress/typedarray-reduceRight.js:
416         * tests/stress/typedarray-some.js:
417
418 2015-10-19  Tim Horton  <timothy_horton@apple.com>
419
420         Add magnify and rotate gesture event support for Mac
421         https://bugs.webkit.org/show_bug.cgi?id=150179
422         <rdar://problem/8036240>
423
424         Reviewed by Darin Adler.
425
426         * Configurations/FeatureDefines.xcconfig:
427         New feature flag.
428
429 2015-10-19  Csaba Osztrogonác  <ossy@webkit.org>
430
431         Fix the ENABLE(WEBASSEMBLY) build after r190827
432         https://bugs.webkit.org/show_bug.cgi?id=150330
433
434         Reviewed by Geoffrey Garen.
435
436         * bytecode/CodeBlock.cpp:
437         (JSC::CodeBlock::CodeBlock): Removed the duplicated VM argument.
438         * bytecode/CodeBlock.h:
439         (JSC::WebAssemblyCodeBlock::create): Added new parameters to finishCreation() calls.
440         (JSC::WebAssemblyCodeBlock::WebAssemblyCodeBlock): Change VM parameter to pointer to match *CodeBlock classes.
441         * runtime/Executable.cpp:
442         (JSC::WebAssemblyExecutable::prepareForExecution): Removed extra ")" and pass pointer as it is expected.
443
444 2015-10-19  Mark Lam  <mark.lam@apple.com>
445
446         DoubleRep fails to convert SpecBoolean values.
447         https://bugs.webkit.org/show_bug.cgi?id=150313
448
449         Reviewed by Geoffrey Garen.
450
451         This was uncovered by the op_sub stress test on 32-bit builds.  On 32-bit builds,
452         DoubleRep will erroneously convert 'true' to a 'NaN' instead of a double 1.
453         On 64-bit, the same issue exists but is masked by another bug in DoubleRep where
454         boolean values will always erroneously trigger a BadType OSR exit.
455
456         The erroneous conversion of 'true' to 'NaN' is because the 'true' case in
457         compileDoubleRep() is missing a jump to the "done" destination.  Instead, it
458         fall through to the "isUndefined" case where it produces a NaN.
459
460         The 64-bit erroneous BadType OSR exit is due to the boolean type check being
461         implemented incorrectly.  It was checking if any bits other than bit 0 were set.
462         However, boolean JS values always have TagBitBool (the 3rd bit) set.  Hence, the
463         check will always fail if we have a boolean value.
464
465         This patch fixes both of these issues.
466
467         No new test is needed because these issues are already covered by scenarios in
468         the op_sub.js stress test.  This patch also fixes the op_sub.js test to throw an
469         exception if any failures are encountered (as expected by the stress test
470         harness).  This patch also re-worked the test code to provide more accurate
471         descriptions of each test scenario for error reporting.
472
473         * dfg/DFGSpeculativeJIT.cpp:
474         (JSC::DFG::SpeculativeJIT::compileDoubleRep):
475
476         * tests/stress/op_sub.js:
477         (generateScenarios):
478         (func):
479         (initializeTestCases):
480         (runTest):
481         (stringify): Deleted.
482
483 2015-10-19  Yusuke Suzuki  <utatane.tea@gmail.com>
484
485         Drop !newTarget check since it always becomes true
486         https://bugs.webkit.org/show_bug.cgi?id=150308
487
488         Reviewed by Geoffrey Garen.
489
490         In a context of calling a constructor, `newTarget` should not become JSEmpty.
491         So `!newTarget` always becomes true. This patch drops this unneccessary check.
492         And to ensure the implementation of the constructor is only called under
493         the context of calling it as a constructor, we change these functions to
494         static and only use them for constructor implementations of InternalFunction.
495
496         * runtime/IntlCollatorConstructor.cpp:
497         (JSC::constructIntlCollator):
498         (JSC::callIntlCollator):
499         * runtime/IntlCollatorConstructor.h:
500         * runtime/IntlDateTimeFormatConstructor.cpp:
501         (JSC::constructIntlDateTimeFormat):
502         (JSC::callIntlDateTimeFormat):
503         * runtime/IntlDateTimeFormatConstructor.h:
504         * runtime/IntlNumberFormatConstructor.cpp:
505         (JSC::constructIntlNumberFormat):
506         (JSC::callIntlNumberFormat):
507         * runtime/IntlNumberFormatConstructor.h:
508         * runtime/JSPromiseConstructor.cpp:
509         (JSC::constructPromise):
510
511 2015-10-18  Yusuke Suzuki  <utatane.tea@gmail.com>
512
513         Promise constructor should throw when not called with "new"
514         https://bugs.webkit.org/show_bug.cgi?id=149380
515
516         Reviewed by Darin Adler.
517
518         Implement handling new.target in Promise constructor. And
519         prohibiting Promise constructor call without "new".
520
521         * runtime/JSPromiseConstructor.cpp:
522         (JSC::constructPromise):
523         (JSC::callPromise):
524         (JSC::JSPromiseConstructor::getCallData):
525         * tests/es6.yaml:
526         * tests/stress/promise-cannot-be-called.js: Added.
527         (shouldBe):
528         (shouldThrow):
529         (Deferred):
530         (super):
531
532 2015-10-18  Yusuke Suzuki  <utatane.tea@gmail.com>
533
534         [ES6] Handle asynchronous tests in tests/es6
535         https://bugs.webkit.org/show_bug.cgi?id=150293
536
537         Reviewed by Darin Adler.
538
539         Since JSC can handle microtasks, some of ES6 Promise tests can be executed under the JSC shell.
540         Some of them still fail because it uses setTimeout that invokes macrotasks with explicit delay.
541
542         * tests/es6.yaml:
543         * tests/es6/Promise_Promise.all.js:
544         (test.asyncTestPassed):
545         (test):
546         * tests/es6/Promise_Promise.all_generic_iterables.js:
547         (test.asyncTestPassed):
548         (test):
549         * tests/es6/Promise_Promise.race.js:
550         (test.asyncTestPassed):
551         (test):
552         * tests/es6/Promise_Promise.race_generic_iterables.js:
553         (test.asyncTestPassed):
554         (test):
555         * tests/es6/Promise_basic_functionality.js:
556         (test.asyncTestPassed):
557         (test):
558         * tests/es6/Promise_is_subclassable_Promise.all.js:
559         (test.asyncTestPassed):
560         (test):
561         * tests/es6/Promise_is_subclassable_Promise.race.js:
562         (test.asyncTestPassed):
563         (test):
564         * tests/es6/Promise_is_subclassable_basic_functionality.js:
565         (test.asyncTestPassed):
566         (test):
567
568 2015-10-18  Sungmann Cho  <sungmann.cho@navercorp.com>
569
570         [Win] Fix the Windows builds.
571         https://bugs.webkit.org/show_bug.cgi?id=150300
572
573         Reviewed by Darin Adler.
574
575         Add missing files to JavaScriptCore.vcxproj.
576
577         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
578         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
579
580 2015-10-17  Filip Pizlo  <fpizlo@apple.com>
581
582         Fix some generational heap growth pathologies
583         https://bugs.webkit.org/show_bug.cgi?id=150270
584
585         Reviewed by Andreas Kling.
586
587         When doing generational copying, we would pretend that the size of old space was increased
588         just by the amount of bytes we copied. In reality, it would be increased by the number of
589         bytes used by the copied blocks we created. This is a larger number, and in some simple
590         pathological programs, the difference can be huge.
591
592         Fixing this bug was relatively easy, and the only really meaningful change here is in
593         Heap::updateAllocationLimits(). But to convince myself that the change was valid, I had to
594         add some debugging code and I had to refactor some stuff so that it made more sense.
595
596         This change does obviate the need for m_totalBytesCopied, because we no longer use it in
597         release builds to decide how much heap we are using at the end of collection. But I added a
598         FIXME about how we could restore our use of m_totalBytesCopied. So, I kept the logic, for
599         now. The FIXME references https://bugs.webkit.org/show_bug.cgi?id=150268.
600
601         Relanding with build fix.
602
603         * CMakeLists.txt:
604         * JavaScriptCore.xcodeproj/project.pbxproj:
605         * heap/CopiedBlock.cpp: Added.
606         (JSC::CopiedBlock::createNoZeroFill):
607         (JSC::CopiedBlock::destroy):
608         (JSC::CopiedBlock::create):
609         (JSC::CopiedBlock::zeroFillWilderness):
610         (JSC::CopiedBlock::CopiedBlock):
611         * heap/CopiedBlock.h:
612         (JSC::CopiedBlock::didSurviveGC):
613         (JSC::CopiedBlock::createNoZeroFill): Deleted.
614         (JSC::CopiedBlock::destroy): Deleted.
615         (JSC::CopiedBlock::create): Deleted.
616         (JSC::CopiedBlock::zeroFillWilderness): Deleted.
617         (JSC::CopiedBlock::CopiedBlock): Deleted.
618         * heap/CopiedSpaceInlines.h:
619         (JSC::CopiedSpace::startedCopying):
620         * heap/Heap.cpp:
621         (JSC::Heap::updateObjectCounts):
622         (JSC::Heap::resetVisitors):
623         (JSC::Heap::capacity):
624         (JSC::Heap::protectedGlobalObjectCount):
625         (JSC::Heap::collectImpl):
626         (JSC::Heap::willStartCollection):
627         (JSC::Heap::updateAllocationLimits):
628         (JSC::Heap::didFinishCollection):
629         (JSC::Heap::sizeAfterCollect): Deleted.
630         * heap/Heap.h:
631         * heap/HeapInlines.h:
632         (JSC::Heap::shouldCollect):
633         (JSC::Heap::isBusy):
634         (JSC::Heap::collectIfNecessaryOrDefer):
635         * heap/MarkedBlock.cpp:
636         (JSC::MarkedBlock::create):
637         (JSC::MarkedBlock::destroy):
638
639 2015-10-17  Commit Queue  <commit-queue@webkit.org>
640
641         Unreviewed, rolling out r191240.
642         https://bugs.webkit.org/show_bug.cgi?id=150281
643
644         Broke 32-bit builds (Requested by smfr on #webkit).
645
646         Reverted changeset:
647
648         "Fix some generational heap growth pathologies"
649         https://bugs.webkit.org/show_bug.cgi?id=150270
650         http://trac.webkit.org/changeset/191240
651
652 2015-10-17  Sungmann Cho  <sungmann.cho@navercorp.com>
653
654         [Win] Fix the Windows build.
655         https://bugs.webkit.org/show_bug.cgi?id=150278
656
657         Reviewed by Brent Fulgham.
658
659         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
660         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
661
662 2015-10-17  Mark Lam  <mark.lam@apple.com>
663
664         Fixed typos from r191224.
665
666         Not reviewed.
667
668         * jit/JITSubGenerator.h:
669         (JSC::JITSubGenerator::generateFastPath):
670
671 2015-10-17  Filip Pizlo  <fpizlo@apple.com>
672
673         Fix some generational heap growth pathologies
674         https://bugs.webkit.org/show_bug.cgi?id=150270
675
676         Reviewed by Andreas Kling.
677
678         When doing generational copying, we would pretend that the size of old space was increased
679         just by the amount of bytes we copied. In reality, it would be increased by the number of
680         bytes used by the copied blocks we created. This is a larger number, and in some simple
681         pathological programs, the difference can be huge.
682
683         Fixing this bug was relatively easy, and the only really meaningful change here is in
684         Heap::updateAllocationLimits(). But to convince myself that the change was valid, I had to
685         add some debugging code and I had to refactor some stuff so that it made more sense.
686
687         This change does obviate the need for m_totalBytesCopied, because we no longer use it in
688         release builds to decide how much heap we are using at the end of collection. But I added a
689         FIXME about how we could restore our use of m_totalBytesCopied. So, I kept the logic, for
690         now. The FIXME references https://bugs.webkit.org/show_bug.cgi?id=150268.
691
692         * CMakeLists.txt:
693         * JavaScriptCore.xcodeproj/project.pbxproj:
694         * heap/CopiedBlock.cpp: Added.
695         (JSC::CopiedBlock::createNoZeroFill):
696         (JSC::CopiedBlock::destroy):
697         (JSC::CopiedBlock::create):
698         (JSC::CopiedBlock::zeroFillWilderness):
699         (JSC::CopiedBlock::CopiedBlock):
700         * heap/CopiedBlock.h:
701         (JSC::CopiedBlock::didSurviveGC):
702         (JSC::CopiedBlock::createNoZeroFill): Deleted.
703         (JSC::CopiedBlock::destroy): Deleted.
704         (JSC::CopiedBlock::create): Deleted.
705         (JSC::CopiedBlock::zeroFillWilderness): Deleted.
706         (JSC::CopiedBlock::CopiedBlock): Deleted.
707         * heap/CopiedSpaceInlines.h:
708         (JSC::CopiedSpace::startedCopying):
709         * heap/Heap.cpp:
710         (JSC::Heap::updateObjectCounts):
711         (JSC::Heap::resetVisitors):
712         (JSC::Heap::capacity):
713         (JSC::Heap::protectedGlobalObjectCount):
714         (JSC::Heap::collectImpl):
715         (JSC::Heap::willStartCollection):
716         (JSC::Heap::updateAllocationLimits):
717         (JSC::Heap::didFinishCollection):
718         (JSC::Heap::sizeAfterCollect): Deleted.
719         * heap/Heap.h:
720         * heap/HeapInlines.h:
721         (JSC::Heap::shouldCollect):
722         (JSC::Heap::isBusy):
723         (JSC::Heap::collectIfNecessaryOrDefer):
724         * heap/MarkedBlock.cpp:
725         (JSC::MarkedBlock::create):
726         (JSC::MarkedBlock::destroy):
727
728 2015-10-16  Yusuke Suzuki  <utatane.tea@gmail.com>
729
730         [ES6] Implement String.prototype.normalize
731         https://bugs.webkit.org/show_bug.cgi?id=150094
732
733         Reviewed by Geoffrey Garen.
734
735         This patch implements String.prototype.normalize leveraging ICU.
736         It can provide the feature applying {NFC, NFD, NFKC, NFKD} normalization to a given string.
737
738         * runtime/StringPrototype.cpp:
739         (JSC::StringPrototype::finishCreation):
740         (JSC::normalize):
741         (JSC::stringProtoFuncNormalize):
742         * tests/es6.yaml:
743         * tests/stress/string-normalize.js: Added.
744         (unicode):
745         (shouldBe):
746         (shouldThrow):
747         (normalizeTest):
748
749 2015-10-16  Geoffrey Garen  <ggaren@apple.com>
750
751         Update JavaScriptCore API docs
752         https://bugs.webkit.org/show_bug.cgi?id=150262
753
754         Reviewed by Mark Lam.
755
756         Apply some edits for clarity. These came out of a docs review.
757
758         * API/JSContext.h:
759         * API/JSExport.h:
760         * API/JSManagedValue.h:
761         * API/JSValue.h:
762
763 2015-10-16  Keith Miller  <keith_miller@apple.com>
764
765         Unreviewed. Fix typo in TypeError messages in TypedArray.prototype.forEach/filter.
766
767         * builtins/TypedArray.prototype.js:
768         (forEach):
769         (filter):
770
771 2015-10-16  Mark Lam  <mark.lam@apple.com>
772
773         Use JITSubGenerator to support UntypedUse operands for op_sub in the DFG.
774         https://bugs.webkit.org/show_bug.cgi?id=150038
775
776         Reviewed by Geoffrey Garen.
777
778         * bytecode/SpeculatedType.h:
779         (JSC::isUntypedSpeculationForArithmetic): Added
780         - Also fixed some comments.
781         
782         * dfg/DFGAbstractInterpreterInlines.h:
783         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
784
785         * dfg/DFGAbstractValue.cpp:
786         (JSC::DFG::AbstractValue::resultType):
787         * dfg/DFGAbstractValue.h:
788         - Added function to compute the ResultType of an operand from its SpeculatedType.
789
790         * dfg/DFGFixupPhase.cpp:
791         (JSC::DFG::FixupPhase::fixupNode):
792         - Fix up ArithSub to speculate its operands to be numbers.  But if an OSR exit
793           due to a BadType was seen at this node, we'll fix it up to expect UntypedUse
794           operands.  This gives the generated code a change to run fast if it only
795           receives numeric operands.
796
797         * dfg/DFGNode.h:
798         (JSC::DFG::Node::shouldSpeculateUntypedForArithmetic):
799
800         * dfg/DFGOperations.cpp:
801         * dfg/DFGOperations.h:
802         - Add the C++ runtime function to implement op_sub when we really encounter the
803           hard types in the operands.
804
805         * dfg/DFGSpeculativeJIT.cpp:
806         (JSC::DFG::SpeculativeJIT::compileArithSub):
807         - Added support for UntypedUse operands using the JITSubGenerator.
808
809         * dfg/DFGSpeculativeJIT.h:
810         (JSC::DFG::SpeculativeJIT::silentSpillAllRegisters):
811         (JSC::DFG::SpeculativeJIT::pickCanTrample):
812         (JSC::DFG::SpeculativeJIT::callOperation):
813
814         * ftl/FTLCapabilities.cpp:
815         (JSC::FTL::canCompile):
816         - Just refuse to FTL compile functions with UntypedUse op_sub operands for now.
817
818         * jit/AssemblyHelpers.h:
819         (JSC::AssemblyHelpers::boxDouble):
820         (JSC::AssemblyHelpers::unboxDoubleNonDestructive):
821         (JSC::AssemblyHelpers::unboxDouble):
822         (JSC::AssemblyHelpers::boxBooleanPayload):
823         * jit/JITArithmetic.cpp:
824         (JSC::JIT::emit_op_sub):
825
826         * jit/JITSubGenerator.h:
827         (JSC::JITSubGenerator::generateFastPath):
828         (JSC::JITSubGenerator::endJumpList):
829         - Added some asserts to document the contract that this generator expects in
830           terms of its incoming registers.
831
832           Also fixed the generated code to not be destructive with regards to incoming
833           registers.  The DFG expects this.
834
835           Also added an endJumpList so that we don't have to jump twice for the fast
836           path where both operands are ints.
837
838         * parser/ResultType.h:
839         (JSC::ResultType::ResultType):
840         - Make the internal Type bits and the constructor private.  Clients should only
841           create ResultType values using one of the provided factory methods.
842
843         * tests/stress/op_sub.js: Added.
844         (o1.valueOf):
845         (stringify):
846         (generateScenarios):
847         (printScenarios):
848         (testCases.func):
849         (func):
850         (initializeTestCases):
851         (runTest):
852         - test op_sub results by comparing one LLINT result against the output of
853           multiple LLINT, and JIT runs.  This test assume that we'll at least get the
854           right result some of the time (if not all the time), and confirms that the
855           various engines produce consistent results for all the various value pairs
856           being tested.
857
858 2015-10-15  Filip Pizlo  <fpizlo@apple.com>
859
860         CopyBarrier must be avoided for slow TypedArrays
861         https://bugs.webkit.org/show_bug.cgi?id=150217
862         rdar://problem/23128791
863
864         Reviewed by Michael Saboff.
865
866         Change how we access array buffer views so that we don't fire the barrier slow path, and
867         don't mask off the spaceBits, if the view is not FastTypedArray. That's because in that case
868         m_vector could be misaligned and so have meaningful non-space data in the spaceBits. Also in
869         that case, m_vector does not point into copied space.
870
871         * dfg/DFGSpeculativeJIT.cpp:
872         (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
873         (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
874         * ftl/FTLLowerDFGToLLVM.cpp:
875         (JSC::FTL::DFG::LowerDFGToLLVM::loadVectorWithBarrier):
876         (JSC::FTL::DFG::LowerDFGToLLVM::copyBarrier):
877         (JSC::FTL::DFG::LowerDFGToLLVM::isInToSpace):
878         (JSC::FTL::DFG::LowerDFGToLLVM::loadButterflyReadOnly):
879         (JSC::FTL::DFG::LowerDFGToLLVM::loadVectorReadOnly):
880         (JSC::FTL::DFG::LowerDFGToLLVM::removeSpaceBits):
881         (JSC::FTL::DFG::LowerDFGToLLVM::isFastTypedArray):
882         (JSC::FTL::DFG::LowerDFGToLLVM::baseIndex):
883         * heap/CopyBarrier.h:
884         (JSC::CopyBarrierBase::getWithoutBarrier):
885         (JSC::CopyBarrierBase::getPredicated):
886         (JSC::CopyBarrierBase::get):
887         (JSC::CopyBarrierBase::copyState):
888         (JSC::CopyBarrier::get):
889         (JSC::CopyBarrier::getPredicated):
890         (JSC::CopyBarrier::set):
891         * heap/Heap.cpp:
892         (JSC::Heap::copyBarrier):
893         * jit/AssemblyHelpers.cpp:
894         (JSC::AssemblyHelpers::branchIfNotType):
895         (JSC::AssemblyHelpers::branchIfFastTypedArray):
896         (JSC::AssemblyHelpers::branchIfNotFastTypedArray):
897         (JSC::AssemblyHelpers::loadTypedArrayVector):
898         (JSC::AssemblyHelpers::purifyNaN):
899         * jit/AssemblyHelpers.h:
900         (JSC::AssemblyHelpers::branchStructure):
901         (JSC::AssemblyHelpers::branchIfToSpace):
902         (JSC::AssemblyHelpers::branchIfNotToSpace):
903         (JSC::AssemblyHelpers::removeSpaceBits):
904         (JSC::AssemblyHelpers::addressForByteOffset):
905         * jit/JITPropertyAccess.cpp:
906         (JSC::JIT::emitIntTypedArrayGetByVal):
907         (JSC::JIT::emitFloatTypedArrayGetByVal):
908         (JSC::JIT::emitIntTypedArrayPutByVal):
909         (JSC::JIT::emitFloatTypedArrayPutByVal):
910         * runtime/JSArrayBufferView.h:
911         (JSC::JSArrayBufferView::vector):
912         (JSC::JSArrayBufferView::length):
913         * runtime/JSArrayBufferViewInlines.h:
914         (JSC::JSArrayBufferView::byteOffset):
915         * runtime/JSGenericTypedArrayView.h:
916         (JSC::JSGenericTypedArrayView::typedVector):
917         * runtime/JSGenericTypedArrayViewInlines.h:
918         (JSC::JSGenericTypedArrayView<Adaptor>::copyBackingStore):
919         (JSC::JSGenericTypedArrayView<Adaptor>::slowDownAndWasteMemory):
920         * tests/stress/misaligned-int8-view-byte-offset.js: Added.
921         * tests/stress/misaligned-int8-view-read.js: Added.
922         * tests/stress/misaligned-int8-view-write.js: Added.
923
924 2015-10-16  Keith Miller  <keith_miller@apple.com>
925
926         Unreviewed. Build fix for 191215.
927
928         * jit/IntrinsicEmitter.cpp:
929
930 2015-10-16  Keith Miller  <keith@Keiths-MacBook-Pro-5.local>
931
932         Add Intrinsic Getters and use them to fix performance on the getters of TypedArray properties.
933         https://bugs.webkit.org/show_bug.cgi?id=149687
934
935         Reviewed by Geoffrey Garen.
936
937         Add the ability to create intrinsic getters in both the inline cache and the DFG/FTL. When the
938         getter fetched by a GetById has an intrinsic we know about we add a new intrinsic access case.
939         Once we get to the DFG, we observe that the access case was an intrinsic and add an appropriate
940         GetByIdVariant. We then parse the intrinsic into an appropriate DFG node.
941
942         The first intrinsics are the new TypedArray prototype getters length, byteLength, and byteOffset.
943
944         * CMakeLists.txt:
945         * JavaScriptCore.xcodeproj/project.pbxproj:
946         * bytecode/GetByIdStatus.cpp:
947         (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
948         (JSC::GetByIdStatus::computeFor):
949         * bytecode/GetByIdVariant.cpp:
950         (JSC::GetByIdVariant::GetByIdVariant):
951         (JSC::GetByIdVariant::operator=):
952         (JSC::GetByIdVariant::canMergeIntrinsicStructures):
953         (JSC::GetByIdVariant::attemptToMerge):
954         (JSC::GetByIdVariant::dumpInContext):
955         * bytecode/GetByIdVariant.h:
956         (JSC::GetByIdVariant::intrinsicFunction):
957         (JSC::GetByIdVariant::intrinsic):
958         (JSC::GetByIdVariant::callLinkStatus): Deleted.
959         * bytecode/PolymorphicAccess.cpp:
960         (JSC::AccessGenerationState::addWatchpoint):
961         (JSC::AccessGenerationState::restoreScratch):
962         (JSC::AccessGenerationState::succeed):
963         (JSC::AccessGenerationState::calculateLiveRegistersForCallAndExceptionHandling):
964         (JSC::AccessGenerationState::preserveLiveRegistersToStackForCall):
965         (JSC::AccessGenerationState::restoreLiveRegistersFromStackForCall):
966         (JSC::AccessGenerationState::restoreLiveRegistersFromStackForCallWithThrownException):
967         (JSC::AccessGenerationState::callSiteIndexForExceptionHandlingOrOriginal):
968         (JSC::AccessGenerationState::originalExceptionHandler):
969         (JSC::AccessGenerationState::originalCallSiteIndex):
970         (JSC::AccessCase::getIntrinsic):
971         (JSC::AccessCase::clone):
972         (JSC::AccessCase::visitWeak):
973         (JSC::AccessCase::generate):
974         (WTF::printInternal):
975         (JSC::AccessCase::AccessCase): Deleted.
976         (JSC::AccessCase::get): Deleted.
977         (JSC::AccessCase::replace): Deleted.
978         (JSC::AccessCase::transition): Deleted.
979         * bytecode/PolymorphicAccess.h:
980         (JSC::AccessCase::isGet):
981         (JSC::AccessCase::isPut):
982         (JSC::AccessCase::isIn):
983         (JSC::AccessCase::intrinsicFunction):
984         (JSC::AccessCase::intrinsic):
985         (JSC::AccessGenerationState::AccessGenerationState):
986         (JSC::AccessGenerationState::liveRegistersForCall):
987         (JSC::AccessGenerationState::callSiteIndexForExceptionHandling):
988         (JSC::AccessGenerationState::numberOfStackBytesUsedForRegisterPreservation):
989         (JSC::AccessGenerationState::needsToRestoreRegistersIfException):
990         (JSC::AccessGenerationState::liveRegistersToPreserveAtExceptionHandlingCallSite):
991         * bytecode/PutByIdVariant.h:
992         (JSC::PutByIdVariant::intrinsic):
993         * dfg/DFGAbstractInterpreterInlines.h:
994         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
995         * dfg/DFGArrayMode.cpp:
996         (JSC::DFG::ArrayMode::alreadyChecked):
997         (JSC::DFG::arrayTypeToString):
998         (JSC::DFG::toTypedArrayType):
999         (JSC::DFG::refineTypedArrayType):
1000         (JSC::DFG::permitsBoundsCheckLowering):
1001         * dfg/DFGArrayMode.h:
1002         (JSC::DFG::ArrayMode::supportsLength):
1003         (JSC::DFG::ArrayMode::isSomeTypedArrayView):
1004         * dfg/DFGByteCodeParser.cpp:
1005         (JSC::DFG::ByteCodeParser::attemptToInlineCall):
1006         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
1007         (JSC::DFG::ByteCodeParser::handleIntrinsicGetter):
1008         (JSC::DFG::ByteCodeParser::load):
1009         (JSC::DFG::ByteCodeParser::handleGetById):
1010         (JSC::DFG::ByteCodeParser::presenceLike): Deleted.
1011         (JSC::DFG::ByteCodeParser::store): Deleted.
1012         * dfg/DFGClobberize.h:
1013         (JSC::DFG::clobberize):
1014         * dfg/DFGFixupPhase.cpp:
1015         (JSC::DFG::FixupPhase::fixupNode):
1016         (JSC::DFG::FixupPhase::convertToGetArrayLength): Deleted.
1017         (JSC::DFG::FixupPhase::prependGetArrayLength): Deleted.
1018         (JSC::DFG::FixupPhase::fixupChecksInBlock): Deleted.
1019         * dfg/DFGGraph.cpp:
1020         (JSC::DFG::Graph::tryGetFoldableView):
1021         * dfg/DFGPredictionPropagationPhase.cpp:
1022         (JSC::DFG::PredictionPropagationPhase::propagate):
1023         * dfg/DFGSpeculativeJIT.cpp:
1024         (JSC::DFG::SpeculativeJIT::checkArray):
1025         (JSC::DFG::SpeculativeJIT::compileGetArrayLength):
1026         * ftl/FTLCapabilities.cpp:
1027         (JSC::FTL::canCompile):
1028         * ftl/FTLLowerDFGToLLVM.cpp:
1029         (JSC::FTL::DFG::LowerDFGToLLVM::compileGetArrayLength):
1030         * jit/IntrinsicEmitter.cpp: Added.
1031         (JSC::AccessCase::canEmitIntrinsicGetter):
1032         (JSC::AccessCase::emitIntrinsicGetter):
1033         * jit/Repatch.cpp:
1034         (JSC::tryCacheGetByID):
1035         * runtime/Intrinsic.h:
1036         * runtime/JSArrayBufferView.cpp:
1037         (JSC::JSArrayBufferView::put):
1038         (JSC::JSArrayBufferView::defineOwnProperty):
1039         (JSC::JSArrayBufferView::deleteProperty):
1040         (JSC::JSArrayBufferView::getOwnNonIndexPropertyNames):
1041         (JSC::JSArrayBufferView::getOwnPropertySlot): Deleted.
1042         (JSC::JSArrayBufferView::finalize): Deleted.
1043         * runtime/JSDataView.cpp:
1044         (JSC::JSDataView::getOwnPropertySlot):
1045         (JSC::JSDataView::put):
1046         (JSC::JSDataView::defineOwnProperty):
1047         (JSC::JSDataView::deleteProperty):
1048         (JSC::JSDataView::getOwnNonIndexPropertyNames):
1049         * runtime/JSDataView.h:
1050         * runtime/JSFunction.h:
1051         * runtime/JSFunctionInlines.h:
1052         (JSC::JSFunction::intrinsic):
1053         * runtime/JSGenericTypedArrayView.h:
1054         * runtime/JSGenericTypedArrayViewInlines.h:
1055         (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlot):
1056         (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
1057         (JSC::JSGenericTypedArrayView<Adaptor>::deleteProperty):
1058         (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlotByIndex): Deleted.
1059         (JSC::JSGenericTypedArrayView<Adaptor>::visitChildren): Deleted.
1060         * runtime/JSObject.cpp:
1061         (JSC::JSObject::putDirectNativeIntrinsicGetter):
1062         * runtime/JSObject.h:
1063         * runtime/JSTypedArrayViewPrototype.cpp:
1064         (JSC::JSTypedArrayViewPrototype::finishCreation):
1065         * tests/stress/typedarray-add-property-to-base-object.js: Added.
1066         (body.foo):
1067         (body):
1068         * tests/stress/typedarray-bad-getter.js: Added.
1069         (body.foo):
1070         (body.get Bar):
1071         (body):
1072         * tests/stress/typedarray-getter-on-self.js: Added.
1073         (body.foo):
1074         (body.bar):
1075         (body.baz):
1076         (body.get for):
1077         (body):
1078         * tests/stress/typedarray-intrinsic-getters-change-prototype.js: Added.
1079         (body.foo):
1080         (body.bar):
1081         (body.baz):
1082         (body):
1083
1084 2015-10-16  Keith Miller  <keith_miller@apple.com>
1085
1086         Fix some issues with TypedArrays
1087         https://bugs.webkit.org/show_bug.cgi?id=150216
1088
1089         Reviewed by Geoffrey Garen.
1090
1091         This fixes a couple of issues:
1092         1) The DFG had a separate case for creating new typedarrays in the dfg when the first argument is an object.
1093            Since the code for creating a Typedarray in the dfg is almost the same as the code in Baseline/LLInt
1094            the two cases have been merged.
1095         2) If the length property on an object was unset then the construction could crash.
1096         3) The TypedArray.prototype.set function and the TypedArray constructor should not call [[Get]] for the
1097            length of the source object when the source object is a TypedArray.
1098         4) The conditions that were used to decide if the iterator could be skipped were incorrect.
1099            Instead of checking for have a bad time we should have checked the Indexing type did not allow for
1100            indexed accessors.
1101
1102         * dfg/DFGOperations.cpp:
1103         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
1104         (JSC::constructGenericTypedArrayViewWithArguments):
1105         (JSC::constructGenericTypedArrayView):
1106         (JSC::constructGenericTypedArrayViewWithFirstArgument): Deleted.
1107
1108 2015-10-16  Anders Carlsson  <andersca@apple.com>
1109
1110         Fix Windows build.
1111
1112         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1113         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1114
1115 2015-10-16  Michael Saboff  <msaboff@apple.com>
1116
1117         REGRESSION (r191175): Still crashing when clicking back button on netflix.com
1118         https://bugs.webkit.org/show_bug.cgi?id=150251
1119
1120         Rubber stamped by Filip Pizlo.
1121
1122         Turning off Tail Calls and disabling tests until the crash is fixed.
1123
1124         * runtime/Options.h:
1125         * tests/es6.yaml:
1126         * tests/stress/dfg-tail-calls.js:
1127         (nonInlinedTailCall.callee):
1128         * tests/stress/mutual-tail-call-no-stack-overflow.js:
1129         (shouldThrow):
1130         * tests/stress/tail-call-in-inline-cache.js:
1131         (tail):
1132         * tests/stress/tail-call-no-stack-overflow.js:
1133         (shouldThrow):
1134         * tests/stress/tail-call-recognize.js:
1135         (callerMustBeRun):
1136         * tests/stress/tail-call-varargs-no-stack-overflow.js:
1137         (shouldThrow):
1138
1139 2015-10-16  Mark Lam  <mark.lam@apple.com>
1140
1141         Add MacroAssembler::callProbe() for supporting lambda JIT probes.
1142         https://bugs.webkit.org/show_bug.cgi?id=150186
1143
1144         Reviewed by Geoffrey Garen.
1145
1146         With callProbe(), we can now make probes that are lambdas.  For example, we can
1147         now conveniently add probes like so: 
1148
1149             // When you know exactly which register you want to inspect:
1150             jit.callProbe([] (MacroAssembler::ProbeContext* context) {
1151                 intptr_t value = reinterpret_cast<intptr_t>(context->cpu.eax);
1152                 dataLogF("eax %p\n", context->cpu.eax); // Inspect the register.
1153                 ASSERT(value > 10); // Add test code for debugging.
1154             });
1155
1156             // When you want to inspect whichever register the JIT allocated:
1157             auto reg = op1.gpr();
1158             jit.callProbe([reg] (MacroAssembler::ProbeContext* context) {
1159                 intptr_t value = reinterpret_cast<intptr_t>(context->gpr(reg));
1160                 dataLogF("reg %s: %ld\n", context->gprName(reg), value);
1161                 ASSERT(value > 10);
1162             });
1163
1164         callProbe() is only meant to be used for debugging sessions.  It is not
1165         appropriate to use it in permanent code (even for debug builds).
1166         This is because:
1167         1. The probe mechanism saves and restores all (and I really mean "all")
1168            registers, and is inherently slow.
1169         2. callProbe() currently works by allocating (via new) a std::function to
1170            guarantee that it is persisted for the duration that the JIT generated code is
1171            live.  We don't currently delete it ever i.e. it leaks a bit of memory each
1172            time the JIT generates code that contains such a lambda probe.
1173
1174         These limitations are acceptable for a debugging session (assuming you're not
1175         debugging a memory leak), but not for deployment code.  If there's a need, we can
1176         plug that leak in another patch.
1177
1178         * assembler/AbstractMacroAssembler.h:
1179         (JSC::AbstractMacroAssembler::CPUState::fpr):
1180         - Removed an unnecessary empty line.
1181         (JSC::AbstractMacroAssembler::ProbeContext::gpr):
1182         (JSC::AbstractMacroAssembler::ProbeContext::fpr):
1183         (JSC::AbstractMacroAssembler::ProbeContext::gprName):
1184         (JSC::AbstractMacroAssembler::ProbeContext::fprName):
1185         - Added some convenience functions that will make using the probe mechanism
1186           easier.
1187
1188         * assembler/MacroAssembler.cpp:
1189         (JSC::StdFunctionData::StdFunctionData):
1190         (JSC::stdFunctionCallback):
1191         (JSC::MacroAssembler::callProbe):
1192         * assembler/MacroAssembler.h:
1193
1194 2015-10-16  Andreas Kling  <akling@apple.com>
1195
1196         Remove unused StructureRareData::m_cachedGenericPropertyNameEnumerator.
1197         <https://webkit.org/b/150244>
1198
1199         Reviewed by Geoffrey Garen.
1200
1201         Remove an unused field from StructureRareData.
1202
1203         * runtime/StructureRareData.cpp:
1204         (JSC::StructureRareData::visitChildren): Deleted.
1205         * runtime/StructureRareData.h:
1206
1207 2015-10-16  Keith Miller  <keith_miller@apple.com>
1208
1209         Unreviewed, rolling out r191190.
1210
1211         Patch needs some design changes.
1212
1213         Reverted changeset:
1214
1215         "Fix some issues with TypedArrays"
1216         https://bugs.webkit.org/show_bug.cgi?id=150216
1217         http://trac.webkit.org/changeset/191190
1218
1219 2015-10-16  Mark Lam  <mark.lam@apple.com>
1220
1221         Move all the probe trampolines into their respective MacroAssembler files.
1222         https://bugs.webkit.org/show_bug.cgi?id=150239
1223
1224         Reviewed by Saam Barati.
1225
1226         This patch does not introduce any behavior changes.  It only moves the
1227         ctiMasmProbeTrampoline implementations from the respective JITStubs<CPU>.h
1228         files to the corresponding MacroAssembler<CPU>.cpp files. 
1229
1230         I also had to make some minor changes to get the code to build after this move:
1231         1. Added #include <wtf/InlineASM.h> in the MacroAssembler<CPU>.cpp files
1232            because the ctiMasmProbeTrampoline is an inline assembly blob.
1233         2. In the moved code, convert MacroAssembler:: qualifiers to the CPU specific
1234            MacroAssembler equivalent.  The referenced entities were always defined in
1235            the CPU specific MacroAssembler anyway, and indirectly referenced through
1236            the generic MacroAssembler.
1237
1238         With this, we can get rid of all the JITStubs<CPU>.cpp files.  There is one
1239         exception: JITStubsMSVC64.asm.  However, that one is unrelated to the probe
1240         mechanism.  So, I'll leave it as is.
1241
1242         We can also remove JITStubs.cpp and JITStubs.h which are now empty except for
1243         some stale unused code.
1244
1245         This patch has been build tested for x86, x86_64, armv7, and arm64.
1246
1247         * CMakeLists.txt:
1248         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1249         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1250         * JavaScriptCore.xcodeproj/project.pbxproj:
1251         * assembler/MacroAssemblerARM.cpp:
1252         (JSC::MacroAssemblerARM::probe):
1253         * assembler/MacroAssemblerARM64.cpp:
1254         (JSC::arm64ProbeTrampoline):
1255         (JSC::MacroAssemblerARM64::probe):
1256         * assembler/MacroAssemblerARMv7.cpp:
1257         (JSC::MacroAssemblerARMv7::probe):
1258         * assembler/MacroAssemblerX86Common.cpp:
1259         * bytecode/CodeBlock.cpp:
1260         * ftl/FTLCompile.cpp:
1261         * ftl/FTLLink.cpp:
1262         * jit/JITArithmetic.cpp:
1263         * jit/JITArithmetic32_64.cpp:
1264         * jit/JITCode.h:
1265         * jit/JITExceptions.cpp:
1266         * jit/JITStubs.cpp: Removed.
1267         * jit/JITStubs.h: Removed.
1268         * jit/JITStubsARM.h: Removed.
1269         * jit/JITStubsARM64.h: Removed.
1270         * jit/JITStubsARMv7.h: Removed.
1271         * jit/JITStubsX86.h: Removed.
1272         * jit/JITStubsX86Common.h: Removed.
1273         * jit/JITStubsX86_64.h: Removed.
1274         * jit/JSInterfaceJIT.h:
1275         * llint/LLIntOffsetsExtractor.cpp:
1276         * runtime/CommonSlowPaths.cpp:
1277
1278 2015-10-16  Keith Miller  <keith_miller@apple.com>
1279
1280         Fix some issues with TypedArrays
1281         https://bugs.webkit.org/show_bug.cgi?id=150216
1282
1283         Reviewed by Michael Saboff.
1284
1285         This fixes a couple of issues:
1286         1) The DFG had a separate case for creating new typedarrays in the dfg when the first argument is an object.
1287            Since the code for creating a Typedarray in the dfg is almost the same as the code in Baseline/LLInt
1288            the two cases have been merged.
1289         2) If the length property on an object was unset then the construction could crash.
1290         3) The TypedArray.prototype.set function and the TypedArray constructor should not call [[Get]] for the
1291            length of the source object when the source object is a TypedArray.
1292         4) The conditions that were used to decide if the iterator could be skipped were incorrect.
1293            Instead of checking for have a bad time we should have checked the Indexing type did not allow for
1294            indexed accessors.
1295
1296         * dfg/DFGOperations.cpp:
1297         (JSC::DFG::newTypedArrayWithOneArgument): Deleted.
1298         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
1299         (JSC::constructGenericTypedArrayViewFromIterator):
1300         (JSC::constructGenericTypedArrayViewWithFirstArgument):
1301         (JSC::constructGenericTypedArrayView):
1302         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
1303         (JSC::genericTypedArrayViewProtoFuncSet):
1304         * tests/stress/typedarray-construct-iterator.js: Added.
1305         (iterator.return.next):
1306         (iterator):
1307         (body):
1308
1309 2015-10-15  Michael Saboff  <msaboff@apple.com>
1310
1311         REGRESSION (r190289): Repro crash clicking back button on netflix.com
1312         https://bugs.webkit.org/show_bug.cgi?id=150220
1313
1314         Reviewed by Geoffrey Garen.
1315
1316         Since constructors check for a valid new "this" object and return it, we can't make
1317         a tail call to another function from within a constructor.
1318
1319         Re-enabled the tail calls and the related tail call tests.
1320
1321         Did some other miscellaneous clean up in the tail call code as part of the debugging.
1322
1323         * bytecompiler/BytecodeGenerator.cpp:
1324         (JSC::BytecodeGenerator::BytecodeGenerator):
1325         * ftl/FTLLowerDFGToLLVM.cpp:
1326         (JSC::FTL::DFG::LowerDFGToLLVM::callPreflight):
1327         * interpreter/Interpreter.h:
1328         (JSC::calleeFrameForVarargs):
1329         * runtime/Options.h:
1330         * tests/es6.yaml:
1331         * tests/stress/dfg-tail-calls.js:
1332         (nonInlinedTailCall.callee):
1333         * tests/stress/mutual-tail-call-no-stack-overflow.js:
1334         (shouldThrow):
1335         * tests/stress/tail-call-in-inline-cache.js:
1336         (tail):
1337         * tests/stress/tail-call-no-stack-overflow.js:
1338         (shouldThrow):
1339         * tests/stress/tail-call-recognize.js:
1340         (callerMustBeRun):
1341         * tests/stress/tail-call-varargs-no-stack-overflow.js:
1342         (shouldThrow):
1343
1344 2015-10-15  Joseph Pecoraro  <pecoraro@apple.com>
1345
1346         Unreviewed. Attempted EFL build fix 2 after r191159.
1347
1348         * PlatformEfl.cmake:
1349
1350 2015-10-15  Joseph Pecoraro  <pecoraro@apple.com>
1351
1352         Unreviewed. Attempted EFL build fix after r191159.
1353
1354         * PlatformEfl.cmake:
1355
1356 2015-10-15  Joseph Pecoraro  <pecoraro@apple.com>
1357
1358         Unreviewed. Build fix after r191160.
1359
1360         * inspector/agents/InspectorHeapAgent.cpp:
1361         (Inspector::InspectorHeapAgent::didGarbageCollect):
1362
1363 2015-10-15  Joseph Pecoraro  <pecoraro@apple.com>
1364
1365         Unreviewed. Revert part of r191159 which caused ASSERTs.
1366
1367         A review comment suggested using WeakPtr. It is not suitable
1368         here and causes ASSERTs across threads. Will address separately.
1369
1370         * inspector/agents/InspectorHeapAgent.h:
1371         * inspector/agents/InspectorHeapAgent.cpp:
1372         (Inspector::InspectorHeapAgent::didGarbageCollect):
1373         (Inspector::InspectorHeapAgent::InspectorHeapAgent): Deleted.
1374
1375 2015-10-14  Joseph Pecoraro  <pecoraro@apple.com>
1376
1377         Web Inspector: Include Garbage Collection Event in Timeline
1378         https://bugs.webkit.org/show_bug.cgi?id=142510
1379
1380         Reviewed by Geoffrey Garen and Brian Burg.
1381
1382         * CMakeLists.txt:
1383         * DerivedSources.make:
1384         * JavaScriptCore.xcodeproj/project.pbxproj:
1385         Include new files in the build.
1386
1387         * heap/HeapObserver.h:
1388         (JSC::HeapObserver::~HeapObserver):
1389         * heap/Heap.cpp:
1390         (JSC::Heap::willStartCollection):
1391         (JSC::Heap::didFinishCollection):
1392         * heap/Heap.h:
1393         (JSC::Heap::addObserver):
1394         (JSC::Heap::removeObserver):
1395         Allow observers on heap to add hooks for starting / ending garbage collection.
1396
1397         * inspector/InspectorEnvironment.h:
1398         * inspector/JSGlobalObjectInspectorController.cpp:
1399         (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
1400         (Inspector::JSGlobalObjectInspectorController::vm):
1401         * inspector/JSGlobalObjectInspectorController.h:
1402         Access the VM through the InspectorEnvironment as it won't change.
1403
1404         * inspector/agents/InspectorHeapAgent.cpp: Added.
1405         (Inspector::InspectorHeapAgent::InspectorHeapAgent):
1406         (Inspector::InspectorHeapAgent::~InspectorHeapAgent):
1407         (Inspector::InspectorHeapAgent::didCreateFrontendAndBackend):
1408         (Inspector::InspectorHeapAgent::willDestroyFrontendAndBackend):
1409         (Inspector::InspectorHeapAgent::enable):
1410         (Inspector::InspectorHeapAgent::disable):
1411         (Inspector::InspectorHeapAgent::gc):
1412         (Inspector::protocolTypeForHeapOperation):
1413         (Inspector::InspectorHeapAgent::willGarbageCollect):
1414         (Inspector::InspectorHeapAgent::didGarbageCollect):
1415         * inspector/agents/InspectorHeapAgent.h: Added.
1416         * inspector/protocol/Heap.json: Added.
1417         New domain and agent to handle tasks related to the JavaScriptCore heap.
1418
1419 2015-10-15  Commit Queue  <commit-queue@webkit.org>
1420
1421         Unreviewed, rolling out r191135.
1422         https://bugs.webkit.org/show_bug.cgi?id=150197
1423
1424         This patch causes 50+ LayoutTest crashes related to the
1425         inspector (Requested by ryanhaddad on #webkit).
1426
1427         Reverted changeset:
1428
1429         "Web Inspector: JavaScriptCore should parse sourceURL and
1430         sourceMappingURL directives"
1431         https://bugs.webkit.org/show_bug.cgi?id=150096
1432         http://trac.webkit.org/changeset/191135
1433
1434 2015-10-15  Geoffrey Garen  <ggaren@apple.com>
1435
1436         Unreviewed, rolling out r191003.
1437         https://bugs.webkit.org/show_bug.cgi?id=150042
1438
1439         We're seeing some crashes in GC beneath speculationFromCell. Maybe this
1440         patch caused them?
1441
1442         Reverted changeset:
1443
1444         CodeBlock write barriers should be precise
1445         https://bugs.webkit.org/show_bug.cgi?id=150042
1446         http://trac.webkit.org/changeset/191003
1447
1448 2015-10-15  Joseph Pecoraro  <pecoraro@apple.com>
1449
1450         Web Inspector: JavaScriptCore should parse sourceURL and sourceMappingURL directives
1451         https://bugs.webkit.org/show_bug.cgi?id=150096
1452
1453         Reviewed by Geoffrey Garen.
1454
1455         * inspector/ContentSearchUtilities.cpp:
1456         (Inspector::ContentSearchUtilities::scriptCommentPattern): Deleted.
1457         (Inspector::ContentSearchUtilities::findScriptSourceURL): Deleted.
1458         (Inspector::ContentSearchUtilities::findScriptSourceMapURL): Deleted.
1459         * inspector/ContentSearchUtilities.h:
1460         No longer need to search script content.
1461
1462         * inspector/ScriptDebugServer.cpp:
1463         (Inspector::ScriptDebugServer::dispatchDidParseSource):
1464         Carry over the sourceURL and sourceMappingURL from the SourceProvider.
1465
1466         * inspector/agents/InspectorDebuggerAgent.cpp:
1467         (Inspector::InspectorDebuggerAgent::sourceMapURLForScript):
1468         (Inspector::InspectorDebuggerAgent::didParseSource):
1469         No longer do content searching.
1470
1471         * parser/Lexer.cpp:
1472         (JSC::Lexer<T>::setCode):
1473         (JSC::Lexer<T>::skipWhitespace):
1474         (JSC::Lexer<T>::parseCommentDirective):
1475         (JSC::Lexer<T>::parseCommentDirectiveValue):
1476         (JSC::Lexer<T>::consume):
1477         (JSC::Lexer<T>::lex):
1478         * parser/Lexer.h:
1479         (JSC::Lexer::sourceURL):
1480         (JSC::Lexer::sourceMappingURL):
1481         (JSC::Lexer::sourceProvider): Deleted.
1482         Give lexer the ability to detect script comment directives.
1483         This just consumes characters in single line comments and
1484         ultimately sets the sourceURL or sourceMappingURL found.
1485
1486         * parser/Parser.h:
1487         (JSC::Parser<LexerType>::parse):
1488         * parser/SourceProvider.h:
1489         (JSC::SourceProvider::url):
1490         (JSC::SourceProvider::sourceURL):
1491         (JSC::SourceProvider::sourceMappingURL):
1492         (JSC::SourceProvider::setSourceURL):
1493         (JSC::SourceProvider::setSourceMappingURL):
1494         After parsing a script, update the Source Provider with the
1495         value of directives that may have been found in the script.
1496
1497 2015-10-15  Filip Pizlo  <fpizlo@apple.com>
1498
1499         InferredTypeTable should ref its keys
1500         https://bugs.webkit.org/show_bug.cgi?id=150138
1501         rdar://problem/23080555
1502
1503         Reviewed by Michael Saboff.
1504
1505         InferredTypeTable was incorrectly using a key hash traits that caused the underlying HashTable to
1506         store keys as UniquedStringImpl* rather than RefPtr<UniquedStringImpl>, even though the HashMap's
1507         nominal key type was RefPtr<UniquedStringImpl>. This arose because I copy-pasted the HashMap type
1508         instantiation from other places and then made random changes to adapt it to my needs, rather than
1509         actually thinking about what I was doing. The solution is to remove the key hash traits argument,
1510         since all it accomplishes is to produce this bug.
1511
1512         The way this bug manifested is probably best described in http://webkit.org/b/150008. After a while
1513         the InferredTypeTable would have dangling references to its strings, if some recompilation or other
1514         thing caused us to drop all other references to those strings. InferredTypeTable is particularly
1515         susceptible to this because it is designed to know about a superset of the property names that its
1516         client Structures know about. The debug assert would then happen when we rehashed the
1517         InferredTypeTable's HashMap, because we'd try to get the hashes of strings that were already
1518         deleted. AFAICT, we didn't have release crashes arising from those strings' memory being returned
1519         to the OS - but it's totally possible that this could have happened. So, we definitely should treat
1520         this bug as more than just a debug issue.
1521
1522         Interestingly, we could have also solved this problem by changing the hash function to use PtrHash.
1523         In all other ways, it's OK for InferredTypeTable to hold dangling references, since it uses the
1524         address of the UniquedStringImpl as a way to name an abstract heap. It's fine if the name of an
1525         abstract heap is a bogus memory address, and it's also fine if that name referred to an entirely
1526         different UniquedStringImpl at some point in the past. That's a nice benefit of any data structure
1527         that keys by abstract heap - if two of them get unified then it's no big deal. I've filed another
1528         bug, http://webkit.org/b/150137 about changing all of our UniquedStringImpl* hashing to use
1529         PtrHash.
1530
1531         * runtime/Identifier.h: Add a comment about http://webkit.org/b/150137.
1532         * runtime/InferredTypeTable.h: Fix the bug.
1533         * tests/stress/inferred-type-table-stale-identifiers.js: Added. I couldn't get this to cause a crash before my change, but it's an interesting test nonetheless.
1534
1535 2015-10-15  Mark Lam  <mark.lam@apple.com>
1536
1537         Add MASM_PROBE support for ARM64.
1538         https://bugs.webkit.org/show_bug.cgi?id=150128
1539
1540         Reviewed by Michael Saboff.
1541
1542         * JavaScriptCore.xcodeproj/project.pbxproj:
1543         * assembler/ARM64Assembler.h:
1544         - Convert the ARM64 registers enum list into a macro list so that we can use
1545           it elsewhere e.g. to declare fields in the probe CPUState.
1546           Also de-tabbed the contents of the ARM64Registers namespace since the enum
1547           list change touches almost all of it anyway. This reduces the amount of
1548           complaints from the style checker.
1549
1550         * assembler/AbstractMacroAssembler.h:
1551         (JSC::AbstractMacroAssembler::CPUState::registerName):
1552         (JSC::AbstractMacroAssembler::CPUState::registerValue):
1553         - Change CPUState methods to allow for registers ID that do not map to one of
1554           its fields. This is needed because ARM64's registers include aliases for some
1555           register names. The CPUState will not allocate separate storage for the
1556           aliases. 
1557
1558         * assembler/MacroAssemblerARM64.cpp: Added.
1559         (JSC::arm64ProbeTrampoline):
1560         - Unlike the probe mechanism for other CPUs, the ARM64 implementation does not
1561           allow the probe function to modify the sp and pc registers.  We insert this
1562           wrapper function between ctiMasmProbeTrampoline() and the user's probe function
1563           so that we can check if the user tried to modify sp and pc.  If so, we will
1564           print an error message so that we can alert the user that we don't support
1565           that on ARM64.
1566
1567           See the comment in ctiMasmProbeTrampoline() in JITStubsARM64.h for details
1568           on why we cannot support sp and pc modifications by the probe function.
1569
1570         (JSC::MacroAssemblerARM64::probe):
1571
1572         * assembler/MacroAssemblerARM64.h:
1573         (JSC::MacroAssemblerARM64::repatchCall):
1574         (JSC::MacroAssemblerARM64::makeBranch):
1575         * jit/JITStubs.cpp:
1576         * jit/JITStubsARM64.h: Added.
1577
1578 2015-10-15  Mark Lam  <mark.lam@apple.com>
1579
1580         Fix some typos in comments.
1581         https://bugs.webkit.org/show_bug.cgi?id=150181
1582
1583         Rubber stamped by Michael Saboff.
1584
1585         * jit/JITStubsARM.h:
1586         * jit/JITStubsARMv7.h:
1587
1588 2015-10-15  Mark Lam  <mark.lam@apple.com>
1589
1590         Refactoring: give the MASM probe CPUState methods shorter names.
1591         https://bugs.webkit.org/show_bug.cgi?id=150177
1592
1593         Reviewed by Michael Saboff.
1594
1595         The existing names are longer than they need to be.  Renaming them as follows:
1596             For GPR, registerName ==> gprName
1597             For GPR, registerValue ==> gpr
1598             For FPR, registerName ==> fprName
1599             For FPR, registerValue ==> fpr
1600
1601         * assembler/AbstractMacroAssembler.h:
1602         (JSC::AbstractMacroAssembler::CPUState::gprName):
1603         (JSC::AbstractMacroAssembler::CPUState::fprName):
1604         (JSC::AbstractMacroAssembler::CPUState::gpr):
1605         (JSC::AbstractMacroAssembler::CPUState::fpr):
1606         (JSC::AbstractMacroAssembler::CPUState::registerName): Deleted.
1607         (JSC::AbstractMacroAssembler::CPUState::registerValue): Deleted.
1608
1609         * assembler/MacroAssemblerPrinter.cpp:
1610         (JSC::printRegister):
1611         (JSC::printMemory):
1612         - Updated to use the new names.
1613
1614 2015-10-15  Yusuke Suzuki  <utatane.tea@gmail.com>
1615
1616         [ES6] Class expression should have lexical environment that has itself as an imutable binding
1617         https://bugs.webkit.org/show_bug.cgi?id=150089
1618
1619         Reviewed by Geoffrey Garen.
1620
1621         According to ES6 spec, class expression has its own lexical environment that holds itself
1622         as an immutable binding[1] (section 14.5.14 step 2, 3, 4, 23)
1623
1624         As a result, even if the binding declared in the outer scope is overridden, methods inside
1625         class expression can refer its class by the class name.
1626
1627         [1]: http://ecma-international.org/ecma-262/6.0/#sec-runtime-semantics-classdefinitionevaluation
1628
1629         * bytecompiler/NodesCodegen.cpp:
1630         (JSC::ClassExprNode::emitBytecode):
1631         * parser/ASTBuilder.h:
1632         (JSC::ASTBuilder::createClassExpr):
1633         * parser/NodeConstructors.h:
1634         (JSC::ClassExprNode::ClassExprNode):
1635         * parser/Nodes.h:
1636         * parser/Parser.cpp:
1637         (JSC::Parser<LexerType>::parseClass):
1638         * parser/SyntaxChecker.h:
1639         (JSC::SyntaxChecker::createClassExpr):
1640         * tests/es6.yaml:
1641         * tests/stress/class-expression-generates-environment.js: Added.
1642         (shouldBe):
1643         (shouldThrow):
1644         (prototype.method):
1645         (staticMethod):
1646         (A.prototype.method):
1647         (A.staticMethod):
1648         (A):
1649         * tests/stress/class-expression-should-be-tdz-in-heritage.js: Added.
1650         (shouldThrow):
1651         (shouldThrow.A):
1652
1653 2015-10-14  Yusuke Suzuki  <utatane.tea@gmail.com>
1654
1655         [ES6] Class method should not declare any variables to upper scope.
1656         https://bugs.webkit.org/show_bug.cgi?id=150115
1657
1658         Reviewed by Geoffrey Garen.
1659
1660         In the current implementation, class methods attempt to declare variables to an upper scope with their method names.
1661         But this is not specified behavior in the ES6 spec.
1662
1663         And as a result, previously, we attempted to declare variables with invalid identifiers.
1664         For example, `class A { 1() { } }` attempt to declare a variable with name `1`.
1665         This (declaring variables with incorrect names) is not allowed in the lexical environment.
1666         And it fires assertions in https://bugs.webkit.org/show_bug.cgi?id=150089.
1667
1668         * parser/Parser.cpp:
1669         (JSC::Parser<LexerType>::parseClass): Deleted.
1670         * tests/stress/class-method-does-not-declare-variable-to-upper-scope.js: Added.
1671         (shouldBe):
1672         (A.prototype.method):
1673         (A.staticMethod):
1674         (A):
1675
1676 2015-10-14  Joseph Pecoraro  <pecoraro@apple.com>
1677
1678         REGRESSION: Web Inspector hangs for many seconds when trying to reload page
1679         https://bugs.webkit.org/show_bug.cgi?id=150065
1680
1681         Reviewed by Mark Lam.
1682
1683         When debugging Web Pages, the same Debugger (PageScriptDebugServer) is
1684         attached to each of the different JSGlobalObjects on the page. This could
1685         mean multiple frames or isolated scripting contexts. Therefore we should
1686         only need to send sourceParsed events to the frontend for scripts within
1687         this new JSGlobalObject, not any JSGlobalObject that has this debugger.
1688
1689         * debugger/Debugger.cpp:
1690         (JSC::Debugger::attach):
1691         Only send sourceParsed events for Scripts in this JSGlobalObject.
1692
1693 2015-10-14  Joseph Pecoraro  <pecoraro@apple.com>
1694
1695         Remove unimplemented methods in CopiedSpace
1696         https://bugs.webkit.org/show_bug.cgi?id=150143
1697
1698         Reviewed by Andreas Kling.
1699
1700         * heap/CopiedSpace.h:
1701
1702 2015-10-14  Brent Fulgham  <bfulgham@apple.com>
1703
1704         [Win] Enforce launcher/library naming scheme
1705         https://bugs.webkit.org/show_bug.cgi?id=150124
1706
1707         Reviewed by Alex Christensen.
1708
1709         * JavaScriptCore.vcxproj/jsc/DLLLauncherMain.cpp: Look for
1710         {name}Lib.dll instead of {name}.dll.
1711         (wWinMain):
1712         * shell/PlatformWin.cmake: Add 'Lib' suffix to DLLs.
1713
1714 2015-10-14  Keith Miller  <keith_miller@apple.com>
1715
1716         ES6 Fix TypedArray constructors.
1717         https://bugs.webkit.org/show_bug.cgi?id=149975
1718
1719         Reviewed by Geoffrey Garen.
1720
1721         The ES6 spec requires that any object argument passed to a TypedArray constructor that is not a TypedArray
1722         and has an iterator should use the iterator to construct the TypedArray. To avoid performance regressions related
1723         to iterating we check if the iterator attached to the object points to the generic array iterator and length is a value.
1724         If so, we do not use the iterator since there should be no observable difference. Another other interesting note is
1725         that the ES6 spec has the of and from functions on a shared constructor between all the TypedArray constructors.
1726         When the TypedArray is constructed the expectation is to crawl the prototype chain of the this value
1727         passed to the function. If the function finds a known TypedArray constructor (Int32Array, Float64Array,...) then
1728         it creates a TypedArray of that type. This is implemented by adding a private function (@allocateTypedArray) to each
1729         of the constructors that can be called in order to construct the array. By using the private functions the JIT should
1730         hopefully be able to optimize this to a direct call.
1731
1732         * CMakeLists.txt:
1733         * JavaScriptCore.xcodeproj/project.pbxproj:
1734         * builtins/TypedArrayConstructor.js: Added.
1735         (of):
1736         (from):
1737         (allocateInt8Array):
1738         (allocateInt16Array):
1739         (allocateInt32Array):
1740         (allocateUint32Array):
1741         (allocateUint16Array):
1742         (allocateUint8Array):
1743         (allocateUint8ClampedArray):
1744         (allocateFloat32Array):
1745         (allocateFloat64Array):
1746         * runtime/CommonIdentifiers.h:
1747         * runtime/JSDataView.cpp:
1748         (JSC::JSDataView::setIndex):
1749         * runtime/JSDataView.h:
1750         * runtime/JSGenericTypedArrayView.h:
1751         (JSC::JSGenericTypedArrayView::toAdaptorNativeFromValue):
1752         * runtime/JSGenericTypedArrayViewConstructor.h:
1753         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
1754         (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::finishCreation):
1755         (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::create):
1756         (JSC::constructGenericTypedArrayViewFromIterator):
1757         (JSC::constructGenericTypedArrayView):
1758         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
1759         (JSC::genericTypedArrayViewProtoFuncIndexOf):
1760         (JSC::genericTypedArrayViewProtoFuncLastIndexOf):
1761         * runtime/JSGlobalObject.cpp:
1762         (JSC::JSGlobalObject::init):
1763         * runtime/JSTypedArrayViewConstructor.cpp: Added.
1764         (JSC::JSTypedArrayViewConstructor::JSTypedArrayViewConstructor):
1765         (JSC::JSTypedArrayViewConstructor::finishCreation):
1766         (JSC::JSTypedArrayViewConstructor::create):
1767         (JSC::JSTypedArrayViewConstructor::createStructure):
1768         (JSC::constructTypedArrayView):
1769         (JSC::JSTypedArrayViewConstructor::getConstructData):
1770         (JSC::JSTypedArrayViewConstructor::getCallData):
1771         * runtime/JSTypedArrayViewConstructor.h: Copied from Source/JavaScriptCore/runtime/JSGenericTypedArrayViewConstructor.h.
1772         * runtime/JSTypedArrayViewPrototype.cpp:
1773         (JSC::JSTypedArrayViewPrototype::create):
1774         * tests/es6.yaml:
1775         * tests/stress/resources/typedarray-constructor-helper-functions.js: Added.
1776         (forEachTypedArray):
1777         (hasSameValues):
1778         (foo):
1779         (testConstructorFunction):
1780         (testConstructor):
1781         * tests/stress/typedarray-constructor.js: Added.
1782         (A):
1783         (iterator.return.next):
1784         (iterator):
1785         (obj.valueOf):
1786         (iterator2.return.next):
1787         (iterator2):
1788         * tests/stress/typedarray-from.js: Added.
1789         (even):
1790         (isBigEnoughAndException):
1791         * tests/stress/typedarray-of.js: Added.
1792
1793 2015-10-14  Mark Lam  <mark.lam@apple.com>
1794
1795         Rename some JSC option names to be more uniform.
1796         https://bugs.webkit.org/show_bug.cgi?id=150127
1797
1798         Reviewed by Geoffrey Garen.
1799
1800         Renaming JSC_enableXXX options to JSC_useXXX, and JSC_showXXX options to JSC_dumpXXX.
1801         Also will renaming a few other miscellaneous to options, to abide by this scheme.
1802
1803         Also renaming some functions to match the option names where relevant.
1804
1805         * API/tests/ExecutionTimeLimitTest.cpp:
1806         (testExecutionTimeLimit):
1807         * assembler/AbstractMacroAssembler.h:
1808         (JSC::optimizeForARMv7IDIVSupported):
1809         (JSC::optimizeForARM64):
1810         (JSC::optimizeForX86):
1811         * assembler/LinkBuffer.cpp:
1812         (JSC::shouldDumpDisassemblyFor):
1813         (JSC::LinkBuffer::finalizeCodeWithoutDisassembly):
1814         (JSC::shouldShowDisassemblyFor): Deleted.
1815         * assembler/LinkBuffer.h:
1816         * bytecode/CodeBlock.cpp:
1817         (JSC::CodeBlock::jettison):
1818         * bytecode/CodeBlockJettisoningWatchpoint.cpp:
1819         (JSC::CodeBlockJettisoningWatchpoint::fireInternal):
1820         * bytecompiler/BytecodeGenerator.cpp:
1821         (JSC::BytecodeGenerator::BytecodeGenerator):
1822         * dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp:
1823         (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::fire):
1824         * dfg/DFGAdaptiveStructureWatchpoint.cpp:
1825         (JSC::DFG::AdaptiveStructureWatchpoint::fireInternal):
1826         * dfg/DFGByteCodeParser.cpp:
1827         (JSC::DFG::ByteCodeParser::handleInlining):
1828         (JSC::DFG::ByteCodeParser::handleGetById):
1829         (JSC::DFG::ByteCodeParser::handlePutById):
1830         (JSC::DFG::ByteCodeParser::parse):
1831         * dfg/DFGCommon.h:
1832         (JSC::DFG::leastUpperBound):
1833         (JSC::DFG::shouldDumpDisassembly):
1834         (JSC::DFG::shouldShowDisassembly): Deleted.
1835         * dfg/DFGDriver.cpp:
1836         (JSC::DFG::compileImpl):
1837         * dfg/DFGJITCompiler.cpp:
1838         (JSC::DFG::JITCompiler::JITCompiler):
1839         (JSC::DFG::JITCompiler::disassemble):
1840         * dfg/DFGJumpReplacement.cpp:
1841         (JSC::DFG::JumpReplacement::fire):
1842         * dfg/DFGOSREntry.cpp:
1843         (JSC::DFG::prepareOSREntry):
1844         * dfg/DFGOSRExitCompiler.cpp:
1845         * dfg/DFGOSRExitFuzz.h:
1846         (JSC::DFG::doOSRExitFuzzing):
1847         * dfg/DFGPlan.cpp:
1848         (JSC::DFG::Plan::compileInThreadImpl):
1849         * dfg/DFGSpeculativeJIT.cpp:
1850         (JSC::DFG::SpeculativeJIT::compileArithSqrt):
1851         * dfg/DFGTierUpCheckInjectionPhase.cpp:
1852         (JSC::DFG::TierUpCheckInjectionPhase::run):
1853         * ftl/FTLCompile.cpp:
1854         (JSC::FTL::mmAllocateDataSection):
1855         * ftl/FTLJITCode.cpp:
1856         (JSC::FTL::JITCode::~JITCode):
1857         * ftl/FTLLowerDFGToLLVM.cpp:
1858         (JSC::FTL::DFG::LowerDFGToLLVM::callCheck):
1859         * ftl/FTLOSRExitCompiler.cpp:
1860         (JSC::FTL::compileStub):
1861         (JSC::FTL::compileFTLOSRExit):
1862         * ftl/FTLState.h:
1863         (JSC::FTL::verboseCompilationEnabled):
1864         (JSC::FTL::shouldDumpDisassembly):
1865         (JSC::FTL::shouldShowDisassembly): Deleted.
1866         * heap/Heap.cpp:
1867         (JSC::Heap::addToRememberedSet):
1868         (JSC::Heap::didFinishCollection):
1869         (JSC::Heap::shouldDoFullCollection):
1870         * heap/Heap.h:
1871         (JSC::Heap::isDeferred):
1872         (JSC::Heap::structureIDTable):
1873         * heap/HeapStatistics.cpp:
1874         (JSC::StorageStatistics::storageCapacity):
1875         (JSC::HeapStatistics::dumpObjectStatistics):
1876         (JSC::HeapStatistics::showObjectStatistics): Deleted.
1877         * heap/HeapStatistics.h:
1878         * interpreter/StackVisitor.cpp:
1879         (JSC::StackVisitor::Frame::createArguments):
1880         * jit/AssemblyHelpers.cpp:
1881         (JSC::AssemblyHelpers::callExceptionFuzz):
1882         * jit/ExecutableAllocationFuzz.cpp:
1883         (JSC::doExecutableAllocationFuzzing):
1884         * jit/ExecutableAllocationFuzz.h:
1885         (JSC::doExecutableAllocationFuzzingIfEnabled):
1886         * jit/JIT.cpp:
1887         (JSC::JIT::privateCompile):
1888         * jit/JITCode.cpp:
1889         (JSC::JITCodeWithCodeRef::~JITCodeWithCodeRef):
1890         * jit/PolymorphicCallStubRoutine.cpp:
1891         (JSC::PolymorphicCallNode::unlink):
1892         (JSC::PolymorphicCallNode::clearCallLinkInfo):
1893         (JSC::PolymorphicCallStubRoutine::PolymorphicCallStubRoutine):
1894         * jit/Repatch.cpp:
1895         (JSC::linkFor):
1896         (JSC::unlinkFor):
1897         (JSC::linkVirtualFor):
1898         * jsc.cpp:
1899         (functionEnableExceptionFuzz):
1900         (jscmain):
1901         * llvm/InitializeLLVM.cpp:
1902         (JSC::initializeLLVMImpl):
1903         * runtime/ExceptionFuzz.cpp:
1904         (JSC::doExceptionFuzzing):
1905         * runtime/ExceptionFuzz.h:
1906         (JSC::doExceptionFuzzingIfEnabled):
1907         * runtime/JSGlobalObject.cpp:
1908         (JSC::JSGlobalObject::init):
1909         * runtime/Options.cpp:
1910         (JSC::recomputeDependentOptions):
1911         (JSC::Options::initialize):
1912         (JSC::Options::dumpOptionsIfNeeded):
1913         (JSC::Options::setOption):
1914         (JSC::Options::dumpAllOptions):
1915         (JSC::Options::dumpAllOptionsInALine):
1916         (JSC::Options::dumpOption):
1917         * runtime/Options.h:
1918         * runtime/VM.cpp:
1919         (JSC::VM::VM):
1920         * runtime/VM.h:
1921         (JSC::VM::exceptionFuzzingBuffer):
1922         * runtime/WriteBarrierInlines.h:
1923         (JSC::WriteBarrierBase<T>::set):
1924         (JSC::WriteBarrierBase<Unknown>::set):
1925         * tests/executableAllocationFuzz.yaml:
1926         * tests/stress/arrowfunction-typeof.js:
1927         * tests/stress/disable-function-dot-arguments.js:
1928         (foo):
1929         * tests/stress/math-sqrt-basics-disable-architecture-specific-optimizations.js:
1930         (sqrtOnInteger):
1931         * tests/stress/regress-148564.js:
1932
1933 2015-10-14  Mark Lam  <mark.lam@apple.com>
1934
1935         Speculative build fix: the CallSiteIndex constructor is explicit and requires an uint32_t.
1936
1937         Not Reviewed.
1938
1939         * bytecode/CodeBlock.cpp:
1940         (JSC::CodeBlock::newExceptionHandlingCallSiteIndex):
1941
1942 2015-10-14  Commit Queue  <commit-queue@webkit.org>
1943
1944         Unreviewed, rolling out r191030.
1945         https://bugs.webkit.org/show_bug.cgi?id=150116
1946
1947         caused js/class-syntax-method-names.html to crash on debug
1948         builds (Requested by alexchristensen_ on #webkit).
1949
1950         Reverted changeset:
1951
1952         "[ES6] Class expression should have lexical environment that
1953         has itself as an imutable binding"
1954         https://bugs.webkit.org/show_bug.cgi?id=150089
1955         http://trac.webkit.org/changeset/191030
1956
1957 2015-10-13  Yusuke Suzuki  <utatane.tea@gmail.com>
1958
1959         [ES6] Class expression should have lexical environment that has itself as an imutable binding
1960         https://bugs.webkit.org/show_bug.cgi?id=150089
1961
1962         Reviewed by Geoffrey Garen.
1963
1964         According to ES6 spec, class expression has its own lexical environment that holds itself
1965         as an immutable binding[1] (section 14.5.14 step 2, 3, 4, 23)
1966
1967         As a result, even if the binding declared in the outer scope is overridden, methods inside
1968         class expression can refer its class by the class name.
1969
1970         [1]: http://ecma-international.org/ecma-262/6.0/#sec-runtime-semantics-classdefinitionevaluation
1971
1972         * bytecompiler/NodesCodegen.cpp:
1973         (JSC::ClassExprNode::emitBytecode):
1974         * parser/ASTBuilder.h:
1975         (JSC::ASTBuilder::createClassExpr):
1976         * parser/NodeConstructors.h:
1977         (JSC::ClassExprNode::ClassExprNode):
1978         * parser/Nodes.h:
1979         * parser/Parser.cpp:
1980         (JSC::Parser<LexerType>::parseClass):
1981         * parser/SyntaxChecker.h:
1982         (JSC::SyntaxChecker::createClassExpr):
1983         * tests/es6.yaml:
1984         * tests/stress/class-expression-generates-environment.js: Added.
1985         (shouldBe):
1986         (shouldThrow):
1987         (prototype.method):
1988         (staticMethod):
1989         (A.prototype.method):
1990         (A.staticMethod):
1991         (A):
1992         * tests/stress/class-expression-should-be-tdz-in-heritage.js: Added.
1993         (shouldThrow):
1994         (shouldThrow.A):
1995
1996 2015-10-13  Saam barati  <sbarati@apple.com>
1997
1998         We were creating a GCAwareJITStubRoutineWithExceptionHandler when we didn't actually have an exception handler in the CodeBlock's exception handler table
1999         https://bugs.webkit.org/show_bug.cgi?id=150016
2000
2001         Reviewed by Geoffrey Garen.
2002
2003         There was a bug where we created a GCAwareJITStubRoutineWithExceptionHandler
2004         for inline caches that were custom setters/getters (but not JS getters/setters).
2005         This is wrong; we only create GCAwareJITStubRoutineWithExceptionHandler when we have
2006         an inline cache with a JS getter/setter call which causes the inline cache to add itself
2007         to the CodeBlock's exception handling table. The problem was that we created
2008         a GCAwareJITStubRoutineWithExceptionHandler that tried to remove itself from
2009         the exception handler table only to find out that it didn't have an entry in the table.
2010
2011         * bytecode/PolymorphicAccess.cpp:
2012         (JSC::PolymorphicAccess::regenerate):
2013
2014 2015-10-13  Joseph Pecoraro  <pecoraro@apple.com>
2015
2016         Simplify WeakBlock visit and reap phases
2017         https://bugs.webkit.org/show_bug.cgi?id=150045
2018
2019         Reviewed by Geoffrey Garen.
2020
2021         WeakBlock visiting and reaping both happen after MarkedBlock marking.
2022         All the MarkedBlocks we encounter should be either Marked or Retired.
2023
2024         * heap/MarkedBlock.h:
2025         (JSC::MarkedBlock::isMarkedOrRetired):
2026         * heap/WeakBlock.cpp:
2027         (JSC::WeakBlock::visit):
2028         (JSC::WeakBlock::reap):
2029         * heap/WeakBlock.h:
2030
2031 2015-10-12  Geoffrey Garen  <ggaren@apple.com>
2032
2033         CodeBlock write barriers should be precise
2034         https://bugs.webkit.org/show_bug.cgi?id=150042
2035
2036         Reviewed by Saam Barati.
2037
2038         CodeBlock performs lots of unnecessary write barriers. This wastes
2039         performance and makes the code a bit harder to follow, and it might mask
2040         important bugs. Now is a good time to unmask important bugs.
2041
2042         * bytecode/CodeBlock.h:
2043         (JSC::CodeBlockSet::mark): Don't write barrier all CodeBlocks on the
2044         stack. Only CodeBlocks that do value profiling need write barriers, and
2045         they do those themselves.
2046
2047         In steady state, when most of our CodeBlocks are old and FTL-compiled,
2048         and we're doing eden GC's, we should almost never visit a CodeBlock.
2049
2050         * dfg/DFGOSRExitCompilerCommon.cpp:
2051         (JSC::DFG::osrWriteBarrier):
2052         (JSC::DFG::adjustAndJumpToTarget): Don't write barrier all inlined
2053         CodeBlocks on exit. That's not necessary. Instead, write barrier the 
2054         CodeBlock(s) we will exit to, along with the one we will write a value
2055         profile to.
2056
2057 2015-10-13  Yusuke Suzuki  <utatane.tea@gmail.com>
2058
2059         REGRESSION: ASSERT (impl->isAtomic()) @ facebook.com
2060         https://bugs.webkit.org/show_bug.cgi?id=149965
2061
2062         Reviewed by Geoffrey Garen.
2063
2064         Edge filtering for CheckIdent ensures that a given value is either Symbol or StringIdent.
2065         However, this filtering is not applied to CheckIdent when propagating a constant value in
2066         the constant folding phase. As a result, it is not guaranteeed that a constant value
2067         propagated in constant folding is Symbol or StringIdent.
2068
2069         * dfg/DFGConstantFoldingPhase.cpp:
2070         (JSC::DFG::ConstantFoldingPhase::foldConstants):
2071
2072 2015-10-12  Yusuke Suzuki  <utatane.tea@gmail.com>
2073
2074         Unreviewed, register symbol structure to fix Debug build
2075         https://bugs.webkit.org/show_bug.cgi?id=149622
2076
2077         Since InferredTypes for String or Symbol claim that they don't have any structure,
2078         `registerInferredType` does not register the structure for Symbol.
2079         We take the similar way to String to fix this issue; Registering Symbol structure
2080         explicitly in DFGStructureRegisterationPhase. Because,
2081
2082         1. InferredType::structure is only allowed for ObjectWithStructure / ObjectWithStructureOrOther.
2083            It looks clear to me that only ObjectWithStructure has structure.
2084         2. Symbol is similar primitive value to String. So handling its structure in similar way to String is nice.
2085
2086         * dfg/DFGStructureRegistrationPhase.cpp:
2087         (JSC::DFG::StructureRegistrationPhase::run):
2088
2089 2015-10-12  Yusuke Suzuki  <utatane.tea@gmail.com>
2090
2091         Iterator loops over key twice after delete
2092         https://bugs.webkit.org/show_bug.cgi?id=149811
2093
2094         Reviewed by Geoffrey Garen.
2095
2096         When an object is the dictionary mode, JSPropertyNameEnumerator collects property names through generic property name enumeration `getPropertyNames`.
2097         The result vector contains indexed property names. But in this case, `publicLength()` may not be 0.
2098         So without disabling indexed names enumeration phase explicitly, JSPropertyNameEnumerator produces indexed property names twice.
2099         One in indexed name enumeration phase, and another in generic property name enumeration phase.
2100         This patch disables indexed names enumeration by setting `indexedLength` to 0 when collecting names through generic property name enumeration.
2101
2102         * runtime/JSPropertyNameEnumerator.h:
2103         (JSC::propertyNameEnumerator):
2104         * tests/stress/property-name-enumerator-should-not-look-into-indexed-values-when-it-is-a-dictionary.js: Added.
2105         (shouldBe):
2106         (col2.of.Reflect.enumerate):
2107
2108 2015-10-12  Yusuke Suzuki  <utatane.tea@gmail.com>
2109
2110         Introduce Symbol type for property type inference
2111         https://bugs.webkit.org/show_bug.cgi?id=149622
2112
2113         Reviewed by Geoffrey Garen.
2114
2115         This patch introduces Symbol type into property type inference.
2116         One of the use cases of ES6 Symbol is enum value. In this case,
2117         we may hold different symbols as the same property of the same structure.
2118         Current property type inference does not support Symbol type, so in the
2119         above case, the property will be inferred as Top type.
2120
2121         * bytecode/PutByIdFlags.h:
2122         * dfg/DFGAbstractValue.cpp:
2123         (JSC::DFG::AbstractValue::set):
2124         * dfg/DFGInferredTypeCheck.cpp:
2125         (JSC::DFG::insertInferredTypeCheck):
2126         * ftl/FTLLowerDFGToLLVM.cpp:
2127         (JSC::FTL::DFG::LowerDFGToLLVM::checkInferredType):
2128         * jit/AssemblyHelpers.cpp:
2129         (JSC::AssemblyHelpers::branchIfNotType):
2130         * llint/LLIntData.cpp:
2131         (JSC::LLInt::Data::performAssertions):
2132         * llint/LowLevelInterpreter.asm:
2133         * llint/LowLevelInterpreter32_64.asm:
2134         * llint/LowLevelInterpreter64.asm:
2135         * runtime/InferredType.cpp:
2136         (JSC::InferredType::kindForFlags):
2137         (JSC::InferredType::Descriptor::forValue):
2138         (JSC::InferredType::Descriptor::putByIdFlags):
2139         (JSC::InferredType::Descriptor::merge):
2140         (WTF::printInternal):
2141         * runtime/InferredType.h:
2142         * tests/stress/prop-type-symbol-then-object.js: Added.
2143         (foo):
2144         (bar):
2145         (toString):
2146         * tests/stress/prop-type-symbol-then-string.js: Added.
2147         (foo):
2148         (bar):
2149
2150 2015-10-12  Joseph Pecoraro  <pecoraro@apple.com>
2151
2152         Web Inspector: Rebaseline Inspector generator tests and make better use of RWIProtocol constant
2153         https://bugs.webkit.org/show_bug.cgi?id=150044
2154
2155         Reviewed by Brian Burg.
2156
2157         * inspector/scripts/codegen/generate_objc_configuration_header.py:
2158         (ObjCConfigurationHeaderGenerator.generate_output):
2159         (ObjCConfigurationHeaderGenerator._generate_configuration_interface_for_domains):
2160         * inspector/scripts/codegen/generate_objc_configuration_implementation.py:
2161         (ObjCBackendDispatcherImplementationGenerator._generate_configuration_implementation_for_domains):
2162         * inspector/scripts/codegen/generate_objc_header.py:
2163         (ObjCHeaderGenerator.generate_output):
2164         * inspector/scripts/codegen/generate_objc_internal_header.py:
2165         (ObjCInternalHeaderGenerator.generate_output):
2166         * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
2167         * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
2168         * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
2169         * inspector/scripts/tests/expected/enum-values.json-result:
2170         * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
2171         * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
2172         * inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
2173         * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
2174         * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
2175         * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
2176         * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
2177         * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
2178         * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
2179
2180 2015-10-12  Myles C. Maxfield  <mmaxfield@apple.com>
2181
2182         Unreviewed build fix
2183
2184         * runtime/JSObject.cpp:
2185         (JSC::JSObject::reallocateAndShrinkButterfly):
2186
2187 2015-10-08  Filip Pizlo  <fpizlo@apple.com>
2188
2189         GC should have a Baker barrier for concurrent copying
2190         https://bugs.webkit.org/show_bug.cgi?id=149852
2191
2192         Reviewed by Geoffrey Garen.
2193
2194         This adds a Baker-style read barrier [1] to copied space accesses. This barrier incurs some
2195         overhead (0%-2% depending on benchmark suite), but what it buys is the ability to make the GC copy
2196         phase concurrent.
2197
2198         The barrier relies on copied space pointers having two "space bits" in the low pointer bits. The
2199         space bits indicate whether the backing store is being copied right now or not, and if it is being
2200         copied, what stage of copying it's in. Two barrier variants are supported:
2201
2202         Read only barrier: if you load a backing store and immediately load from it without doing anything
2203         else, you can just mask off the bits. In the worst case, you'll get the old backing store while
2204         some copying thread is already allocating and populating the new version of the backing store. But
2205         in that case, forwarding to the new backing store will not enable you to load a more up-to-date
2206         value from the backing store. So, just masking the bits is enough. The read-only barrier is only
2207         used in ICs where we know that we are only reading, and opportunistically within the DFG and FTL
2208         thanks to the CopyBarrierOptimizationPhase. We never explicitly emit a read-only barrier in those
2209         compilers; instead the phase will turn a GetButterfly into GetButterflyReadOnly if it proves that a
2210         bunch of requirements are met.
2211
2212         Normal barrier: if the space bits are non-zero, call a slow path. The slow path will either do
2213         nothing (if the copy phase hasn't started yet), or it will copy the backing store and update the
2214         pointer (if the copy phase hasn't gotten around to copying this particular backing store), or it
2215         will wait for the copying thread to finish (if some thread is copying this backing store right
2216         now), or it will do nothing (if by the time we called into the slow path the backing store was
2217         already copied). This is just like Baker's CAR/CDR barrier, but with a lock thrown in to handle
2218         concurrent execution.
2219
2220         This is a 1% slow-down on SunSpider, a 1.5% slow-down on Octane, a 1.5% slow-down on Kraken, and a
2221         0% slow-down on AsmBench. Note that the Octane slow-down is excluding the SplayLatency benchmark.
2222         That benchmark will eventually speed up a lot once we finish doing all of this stuff. Probably, the
2223         JetStream splay-latency will see an even larger speed-up, since our version of the latency tests do
2224         a better job of punishing bad worst-case behavior.
2225
2226         [1] http://dspace.mit.edu/bitstream/handle/1721.1/41976/AI_WP_139.pdf, look for the CAR and CDR
2227         procedures on page 9.
2228
2229         * CMakeLists.txt:
2230         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2231         * JavaScriptCore.xcodeproj/project.pbxproj:
2232         * bytecode/PolymorphicAccess.cpp:
2233         (JSC::AccessCase::generate):
2234         * dfg/DFGAbstractInterpreterInlines.h:
2235         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2236         * dfg/DFGArgumentsEliminationPhase.cpp:
2237         * dfg/DFGClobberize.h:
2238         (JSC::DFG::clobberize):
2239         * dfg/DFGCopyBarrierOptimizationPhase.cpp: Added.
2240         (JSC::DFG::performCopyBarrierOptimization):
2241         * dfg/DFGCopyBarrierOptimizationPhase.h: Added.
2242         * dfg/DFGDoesGC.cpp:
2243         (JSC::DFG::doesGC):
2244         * dfg/DFGFixupPhase.cpp:
2245         (JSC::DFG::FixupPhase::fixupNode):
2246         * dfg/DFGHeapLocation.cpp:
2247         (WTF::printInternal):
2248         * dfg/DFGHeapLocation.h:
2249         * dfg/DFGLICMPhase.cpp:
2250         (JSC::DFG::LICMPhase::run):
2251         * dfg/DFGNodeType.h:
2252         * dfg/DFGOperations.cpp:
2253         * dfg/DFGOperations.h:
2254         * dfg/DFGPlan.cpp:
2255         (JSC::DFG::Plan::compileInThreadImpl):
2256         * dfg/DFGPredictionPropagationPhase.cpp:
2257         (JSC::DFG::PredictionPropagationPhase::propagate):
2258         * dfg/DFGSafeToExecute.h:
2259         (JSC::DFG::safeToExecute):
2260         * dfg/DFGSpeculativeJIT.cpp:
2261         (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
2262         (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
2263         (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
2264         (JSC::DFG::SpeculativeJIT::compileGetButterfly):
2265         (JSC::DFG::SpeculativeJIT::temporaryRegisterForPutByVal):
2266         * dfg/DFGSpeculativeJIT.h:
2267         * dfg/DFGSpeculativeJIT32_64.cpp:
2268         (JSC::DFG::SpeculativeJIT::compile):
2269         * dfg/DFGSpeculativeJIT64.cpp:
2270         (JSC::DFG::SpeculativeJIT::compile):
2271         * dfg/DFGTypeCheckHoistingPhase.cpp:
2272         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
2273         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
2274         * ftl/FTLCapabilities.cpp:
2275         (JSC::FTL::canCompile):
2276         * ftl/FTLLowerDFGToLLVM.cpp:
2277         (JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
2278         (JSC::FTL::DFG::LowerDFGToLLVM::compileGetButterfly):
2279         (JSC::FTL::DFG::LowerDFGToLLVM::compileGetButterflyReadOnly):
2280         (JSC::FTL::DFG::LowerDFGToLLVM::compileConstantStoragePointer):
2281         (JSC::FTL::DFG::LowerDFGToLLVM::compileGetIndexedPropertyStorage):
2282         (JSC::FTL::DFG::LowerDFGToLLVM::compileCheckArray):
2283         (JSC::FTL::DFG::LowerDFGToLLVM::compileGetTypedArrayByteOffset):
2284         (JSC::FTL::DFG::LowerDFGToLLVM::compileMultiGetByOffset):
2285         (JSC::FTL::DFG::LowerDFGToLLVM::compileMultiPutByOffset):
2286         (JSC::FTL::DFG::LowerDFGToLLVM::compileGetDirectPname):
2287         (JSC::FTL::DFG::LowerDFGToLLVM::storageForTransition):
2288         (JSC::FTL::DFG::LowerDFGToLLVM::getById):
2289         (JSC::FTL::DFG::LowerDFGToLLVM::loadButterflyWithBarrier):
2290         (JSC::FTL::DFG::LowerDFGToLLVM::loadVectorWithBarrier):
2291         (JSC::FTL::DFG::LowerDFGToLLVM::copyBarrier):
2292         (JSC::FTL::DFG::LowerDFGToLLVM::loadButterflyReadOnly):
2293         (JSC::FTL::DFG::LowerDFGToLLVM::loadVectorReadOnly):
2294         (JSC::FTL::DFG::LowerDFGToLLVM::removeSpaceBits):
2295         (JSC::FTL::DFG::LowerDFGToLLVM::baseIndex):
2296         * ftl/FTLOperations.cpp:
2297         (JSC::FTL::operationNewObjectWithButterfly):
2298         (JSC::FTL::operationPopulateObjectInOSR):
2299         * ftl/FTLOutput.h:
2300         (JSC::FTL::Output::testNonZero32):
2301         (JSC::FTL::Output::testIsZero64):
2302         (JSC::FTL::Output::testNonZero64):
2303         (JSC::FTL::Output::testIsZeroPtr):
2304         (JSC::FTL::Output::testNonZeroPtr):
2305         (JSC::FTL::Output::select):
2306         (JSC::FTL::Output::extractValue):
2307         * heap/CopyBarrier.h: Copied from Source/JavaScriptCore/heap/CopyWriteBarrier.h.
2308         (JSC::CopyBarrierBase::CopyBarrierBase):
2309         (JSC::CopyBarrierBase::operator!):
2310         (JSC::CopyBarrierBase::operator bool):
2311         (JSC::CopyBarrierBase::getWithoutBarrier):
2312         (JSC::CopyBarrierBase::get):
2313         (JSC::CopyBarrierBase::copyState):
2314         (JSC::CopyBarrierBase::setCopyState):
2315         (JSC::CopyBarrierBase::clear):
2316         (JSC::CopyBarrierBase::set):
2317         (JSC::CopyBarrierBase::setWithoutBarrier):
2318         (JSC::CopyBarrierBase::weakCASWithoutBarrier):
2319         (JSC::CopyBarrier::CopyBarrier):
2320         (JSC::CopyBarrier::getWithoutBarrier):
2321         (JSC::CopyBarrier::get):
2322         (JSC::CopyBarrier::set):
2323         (JSC::CopyBarrier::setWithoutBarrier):
2324         (JSC::CopyBarrier::weakCASWithoutBarrier):
2325         (JSC::CopyWriteBarrier::CopyWriteBarrier): Deleted.
2326         (JSC::CopyWriteBarrier::operator!): Deleted.
2327         (JSC::CopyWriteBarrier::operator bool): Deleted.
2328         (JSC::CopyWriteBarrier::get): Deleted.
2329         (JSC::CopyWriteBarrier::operator*): Deleted.
2330         (JSC::CopyWriteBarrier::operator->): Deleted.
2331         (JSC::CopyWriteBarrier::set): Deleted.
2332         (JSC::CopyWriteBarrier::setWithoutWriteBarrier): Deleted.
2333         (JSC::CopyWriteBarrier::clear): Deleted.
2334         * heap/CopyVisitorInlines.h:
2335         (JSC::CopyVisitor::checkIfShouldCopy):
2336         * heap/CopyWriteBarrier.h: Removed.
2337         * heap/Heap.cpp:
2338         (JSC::Heap::addToRememberedSet):
2339         (JSC::Heap::copyBarrier):
2340         (JSC::Heap::collectAndSweep):
2341         * heap/Heap.h:
2342         (JSC::Heap::writeBarrierBuffer):
2343         * heap/HeapInlines.h:
2344         * jit/AssemblyHelpers.h:
2345         (JSC::AssemblyHelpers::branchStructure):
2346         (JSC::AssemblyHelpers::branchIfNotToSpace):
2347         (JSC::AssemblyHelpers::removeSpaceBits):
2348         (JSC::AssemblyHelpers::addressForByteOffset):
2349         * jit/JIT.cpp:
2350         (JSC::JIT::privateCompileMainPass):
2351         (JSC::JIT::privateCompileSlowCases):
2352         * jit/JITOpcodes.cpp:
2353         (JSC::JIT::emitSlow_op_has_indexed_property):
2354         (JSC::JIT::emit_op_get_direct_pname):
2355         (JSC::JIT::emitSlow_op_get_direct_pname):
2356         * jit/JITOpcodes32_64.cpp:
2357         (JSC::JIT::emit_op_get_direct_pname):
2358         (JSC::JIT::emitSlow_op_get_direct_pname):
2359         * jit/JITPropertyAccess.cpp:
2360         (JSC::JIT::emitDoubleLoad):
2361         (JSC::JIT::emitContiguousLoad):
2362         (JSC::JIT::emitArrayStorageLoad):
2363         (JSC::JIT::emitSlow_op_get_by_val):
2364         (JSC::JIT::emitGenericContiguousPutByVal):
2365         (JSC::JIT::emitArrayStoragePutByVal):
2366         (JSC::JIT::emitSlow_op_put_by_val):
2367         (JSC::JIT::emit_op_get_from_scope):
2368         (JSC::JIT::emitSlow_op_get_from_scope):
2369         (JSC::JIT::emit_op_put_to_scope):
2370         (JSC::JIT::emitSlow_op_put_to_scope):
2371         (JSC::JIT::emitIntTypedArrayGetByVal):
2372         (JSC::JIT::emitFloatTypedArrayGetByVal):
2373         (JSC::JIT::emitIntTypedArrayPutByVal):
2374         (JSC::JIT::emitFloatTypedArrayPutByVal):
2375         * llint/LowLevelInterpreter.asm:
2376         * llint/LowLevelInterpreter64.asm:
2377         * runtime/DirectArguments.cpp:
2378         (JSC::DirectArguments::visitChildren):
2379         (JSC::DirectArguments::copyBackingStore):
2380         (JSC::DirectArguments::overrideThings):
2381         (JSC::DirectArguments::overrideThingsIfNecessary):
2382         (JSC::DirectArguments::overrideArgument):
2383         (JSC::DirectArguments::copyToArguments):
2384         * runtime/DirectArguments.h:
2385         (JSC::DirectArguments::canAccessIndexQuickly):
2386         (JSC::DirectArguments::canAccessArgumentIndexQuicklyInDFG):
2387         * runtime/JSArray.cpp:
2388         (JSC::JSArray::setLength):
2389         (JSC::JSArray::pop):
2390         (JSC::JSArray::push):
2391         (JSC::JSArray::fastSlice):
2392         (JSC::JSArray::fastConcatWith):
2393         (JSC::JSArray::shiftCountWithArrayStorage):
2394         (JSC::JSArray::shiftCountWithAnyIndexingType):
2395         (JSC::JSArray::unshiftCountWithAnyIndexingType):
2396         (JSC::JSArray::fillArgList):
2397         (JSC::JSArray::copyToArguments):
2398         * runtime/JSArrayBufferView.cpp:
2399         (JSC::JSArrayBufferView::ConstructionContext::ConstructionContext):
2400         (JSC::JSArrayBufferView::JSArrayBufferView):
2401         (JSC::JSArrayBufferView::finishCreation):
2402         (JSC::JSArrayBufferView::finalize):
2403         * runtime/JSArrayBufferView.h:
2404         (JSC::JSArrayBufferView::vector):
2405         (JSC::JSArrayBufferView::length):
2406         * runtime/JSArrayBufferViewInlines.h:
2407         (JSC::JSArrayBufferView::neuter):
2408         (JSC::JSArrayBufferView::byteOffset):
2409         * runtime/JSGenericTypedArrayView.h:
2410         (JSC::JSGenericTypedArrayView::typedVector):
2411         * runtime/JSGenericTypedArrayViewInlines.h:
2412         (JSC::JSGenericTypedArrayView<Adaptor>::visitChildren):
2413         (JSC::JSGenericTypedArrayView<Adaptor>::copyBackingStore):
2414         (JSC::JSGenericTypedArrayView<Adaptor>::slowDownAndWasteMemory):
2415         * runtime/JSMap.h:
2416         (JSC::JSMap::JSMap):
2417         * runtime/JSObject.cpp:
2418         (JSC::JSObject::copyButterfly):
2419         (JSC::JSObject::visitChildren):
2420         (JSC::JSObject::copyBackingStore):
2421         (JSC::JSObject::getOwnPropertySlotByIndex):
2422         (JSC::JSObject::putByIndex):
2423         (JSC::JSObject::enterDictionaryIndexingMode):
2424         (JSC::JSObject::createInitialIndexedStorage):
2425         (JSC::JSObject::createArrayStorage):
2426         (JSC::JSObject::convertUndecidedToInt32):
2427         (JSC::JSObject::convertUndecidedToDouble):
2428         (JSC::JSObject::convertUndecidedToContiguous):
2429         (JSC::JSObject::constructConvertedArrayStorageWithoutCopyingElements):
2430         (JSC::JSObject::convertUndecidedToArrayStorage):
2431         (JSC::JSObject::convertInt32ToDouble):
2432         (JSC::JSObject::convertInt32ToContiguous):
2433         (JSC::JSObject::convertInt32ToArrayStorage):
2434         (JSC::JSObject::convertDoubleToContiguous):
2435         (JSC::JSObject::convertDoubleToArrayStorage):
2436         (JSC::JSObject::convertContiguousToArrayStorage):
2437         (JSC::JSObject::setIndexQuicklyToUndecided):
2438         (JSC::JSObject::ensureArrayStorageExistsAndEnterDictionaryIndexingMode):
2439         (JSC::JSObject::deletePropertyByIndex):
2440         (JSC::JSObject::getOwnPropertyNames):
2441         (JSC::JSObject::putIndexedDescriptor):
2442         (JSC::JSObject::defineOwnIndexedProperty):
2443         (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes):
2444         (JSC::JSObject::putDirectIndexBeyondVectorLength):
2445         (JSC::JSObject::getNewVectorLength):
2446         (JSC::JSObject::ensureLengthSlow):
2447         (JSC::JSObject::reallocateAndShrinkButterfly):
2448         (JSC::JSObject::growOutOfLineStorage):
2449         (JSC::JSObject::getOwnPropertyDescriptor):
2450         (JSC::JSObject::getEnumerableLength):
2451         * runtime/JSObject.h:
2452         (JSC::JSObject::getArrayLength):
2453         (JSC::JSObject::getVectorLength):
2454         (JSC::JSObject::canGetIndexQuickly):
2455         (JSC::JSObject::getIndexQuickly):
2456         (JSC::JSObject::tryGetIndexQuickly):
2457         (JSC::JSObject::canSetIndexQuickly):
2458         (JSC::JSObject::canSetIndexQuicklyForPutDirect):
2459         (JSC::JSObject::setIndexQuickly):
2460         (JSC::JSObject::initializeIndex):
2461         (JSC::JSObject::hasSparseMap):
2462         (JSC::JSObject::inSparseIndexingMode):
2463         (JSC::JSObject::inlineStorage):
2464         (JSC::JSObject::butterfly):
2465         (JSC::JSObject::outOfLineStorage):
2466         (JSC::JSObject::locationForOffset):
2467         (JSC::JSObject::ensureInt32):
2468         (JSC::JSObject::ensureDouble):
2469         (JSC::JSObject::ensureContiguous):
2470         (JSC::JSObject::ensureArrayStorage):
2471         (JSC::JSObject::arrayStorage):
2472         (JSC::JSObject::arrayStorageOrNull):
2473         (JSC::JSObject::ensureLength):
2474         (JSC::JSObject::putDirectWithoutTransition):
2475         * runtime/JSSet.h:
2476         (JSC::JSSet::JSSet):
2477         * runtime/MapData.h:
2478         (JSC::JSIterator>::MapDataImpl):
2479         (JSC::JSIterator>::IteratorData::next):
2480         (JSC::JSIterator>::IteratorData::refreshCursor):
2481         * runtime/MapDataInlines.h:
2482         (JSC::JSIterator>::clear):
2483         (JSC::JSIterator>::find):
2484         (JSC::JSIterator>::add):
2485         (JSC::JSIterator>::remove):
2486         (JSC::JSIterator>::replaceAndPackBackingStore):
2487         (JSC::JSIterator>::replaceBackingStore):
2488         (JSC::JSIterator>::ensureSpaceForAppend):
2489         (JSC::JSIterator>::visitChildren):
2490         (JSC::JSIterator>::copyBackingStore):
2491         * runtime/Options.h:
2492
2493 2015-10-12  Saam barati  <sbarati@apple.com>
2494
2495         Update JSC features.json
2496         https://bugs.webkit.org/show_bug.cgi?id=150043
2497
2498         Reviewed by Mark Lam.
2499
2500         There were a lot of things implemented that weren't in
2501         the list. We should be better about updating the list
2502         as we land patches for new ES6 features.
2503
2504         * features.json:
2505
2506 2015-10-12  Joseph Pecoraro  <pecoraro@apple.com>
2507
2508         Cleanup Heap.h and some related headers
2509         https://bugs.webkit.org/show_bug.cgi?id=149981
2510
2511         Reviewed by Geoffrey Garen.
2512
2513         * heap/Heap.h:
2514         - Some functions did not need export.
2515         - threadDupStrings never had an implementation.
2516
2517         * heap/ConservativeRoots.cpp:
2518         * heap/ConservativeRoots.h:
2519         * heap/Heap.cpp:
2520         * heap/ListableHandler.h:
2521         * heap/WeakReferenceHarvester.h:
2522         * jit/Repatch.cpp:
2523         * runtime/JSONObject.h:
2524         * runtime/VM.h:
2525         - Stale forward declarations / includes.
2526
2527 2015-10-12  Saam barati  <sbarati@apple.com>
2528
2529         Each *ById inline cache in the FTL must have its own CallSiteIndex
2530         https://bugs.webkit.org/show_bug.cgi?id=150039
2531
2532         Reviewed by Geoffrey Garen and Filip Pizlo.
2533
2534         When lowering to LLVM, we create a patchpoint intrinsic for each
2535         *ById in DFG IR. LLVM may choose to duplicate these patchpoints.
2536         Therefore, we want each resulting inline cache to have a unique
2537         CallSiteIndex because each inline cache will have its own set of 
2538         used registers. This change is necessary when we implement try/catch 
2539         in the FTL because an inline cache will ask for the set of used 
2540         registers it will need to restore in the event of an exception 
2541         being thrown. It asks for this set of registers by giving JITCode
2542         a CallSiteIndex. Because each corresponding inline cache that results
2543         from a duplicated patchpoint may all ask this for this set of registers, 
2544         we must assign each inline cache a unique CallSiteIndex.
2545
2546         * bytecode/CodeBlock.cpp:
2547         (JSC::CodeBlock::newExceptionHandlingCallSiteIndex):
2548         * dfg/DFGCommonData.cpp:
2549         (JSC::DFG::CommonData::addCodeOrigin):
2550         (JSC::DFG::CommonData::addUniqueCallSiteIndex):
2551         (JSC::DFG::CommonData::addCodeOriginUnconditionally): Deleted.
2552         * dfg/DFGCommonData.h:
2553         * ftl/FTLCompile.cpp:
2554         (JSC::FTL::mmAllocateDataSection):
2555         * ftl/FTLInlineCacheDescriptor.h:
2556         (JSC::FTL::InlineCacheDescriptor::InlineCacheDescriptor):
2557         (JSC::FTL::InlineCacheDescriptor::stackmapID):
2558         (JSC::FTL::InlineCacheDescriptor::codeOrigin):
2559         (JSC::FTL::InlineCacheDescriptor::uid):
2560         (JSC::FTL::GetByIdDescriptor::GetByIdDescriptor):
2561         (JSC::FTL::PutByIdDescriptor::PutByIdDescriptor):
2562         (JSC::FTL::CheckInDescriptor::CheckInDescriptor):
2563         (JSC::FTL::LazySlowPathDescriptor::LazySlowPathDescriptor):
2564         (JSC::FTL::InlineCacheDescriptor::callSiteIndex): Deleted.
2565         * ftl/FTLLowerDFGToLLVM.cpp:
2566         (JSC::FTL::DFG::LowerDFGToLLVM::compilePutById):
2567         (JSC::FTL::DFG::LowerDFGToLLVM::compileIn):
2568         (JSC::FTL::DFG::LowerDFGToLLVM::getById):
2569         (JSC::FTL::DFG::LowerDFGToLLVM::lazySlowPath):
2570
2571 2015-10-12  Andreas Kling  <akling@apple.com>
2572
2573         "A + B" with strings shouldn't copy if A or B is empty.
2574         <https://webkit.org/b/150034>
2575
2576         Reviewed by Anders Carlsson.
2577
2578         * runtime/JSStringBuilder.h:
2579         (JSC::jsMakeNontrivialString):
2580         * runtime/Lookup.cpp:
2581         (JSC::reifyStaticAccessor):
2582         * runtime/ObjectPrototype.cpp:
2583         (JSC::objectProtoFuncToString):
2584
2585 2015-10-12  Joseph Pecoraro  <pecoraro@apple.com>
2586
2587         VisitedValueCount GC Counter misses parallel SlotVisitors
2588         https://bugs.webkit.org/show_bug.cgi?id=149980
2589
2590         Reviewed by Geoffrey Garen.
2591
2592         * heap/Heap.cpp:
2593         (JSC::Heap::updateObjectCounts):
2594         Include threaded slot visitor's object counts in the debugging value.
2595
2596 2015-10-12  Filip Pizlo  <fpizlo@apple.com>
2597
2598         Unreviewed, fix non-FTL build for real.
2599
2600         * ftl/FTLLazySlowPath.h:
2601
2602 2015-10-12  Filip Pizlo  <fpizlo@apple.com>
2603
2604         Unreviewed, clarify a comment. The example code had a bug.
2605
2606         * ftl/FTLLowerDFGToLLVM.cpp:
2607
2608 2015-10-12  Filip Pizlo  <fpizlo@apple.com>
2609
2610         Unreviewed, fix no-FTL build.
2611
2612         * ftl/FTLLazySlowPath.cpp:
2613
2614 2015-10-12  Philip Chimento  <philip.chimento@gmail.com>
2615
2616         webkit-gtk 2.3.3 fails to build on OS X - Conflicting type "Fixed"
2617         https://bugs.webkit.org/show_bug.cgi?id=126433
2618
2619         Reviewed by Philippe Normand
2620
2621         Don't include CoreFoundation.h when building the GTK port.
2622
2623         * Source/JavaScriptCore/API/WebKitAvailability.h: Add !defined(BUILDING_GTK__) to defined(__APPLE__).
2624
2625 2015-10-10  Filip Pizlo  <fpizlo@apple.com>
2626
2627         FTL should generate code to call slow paths lazily
2628         https://bugs.webkit.org/show_bug.cgi?id=149936
2629
2630         Reviewed by Saam Barati.
2631
2632         We often have complex slow paths in FTL-generated code. Those slow paths may never run. Even
2633         if they do run, they don't need stellar performance. So, it doesn't make sense to have LLVM
2634         worry about compiling such slow path code.
2635
2636         This patch enables us to use our own MacroAssembler for compiling the slow path inside FTL
2637         code. It does this by using a crazy lambda thingy (see FTLLowerDFGToLLVM.cpp's lazySlowPath()
2638         and its documentation). The result is quite natural to use.
2639
2640         Even for straight slow path calls via something like vmCall(), the lazySlowPath offers the
2641         benefit that the call marshalling and the exception checking are not expressed using LLVM IR
2642         and do not require LLVM to think about it. It also has the benefit that we never generate the
2643         code if it never runs. That's great, since function calls usually involve ~10 instructions
2644         total (move arguments to argument registers, make the call, check exception, etc.).
2645
2646         This patch adds the lazy slow path abstraction and uses it for some slow paths in the FTL.
2647         The code we generate with lazy slow paths is worse than the code that LLVM would have
2648         generated. Therefore, a lazy slow path only makes sense when we have strong evidence that
2649         the slow path will execute infrequently relative to the fast path. This completely precludes
2650         the use of lazy slow paths for out-of-line Nodes that unconditionally call a C++ function.
2651         It also precludes their use for the GetByVal out-of-bounds handler, since when we generate
2652         a GetByVal with an out-of-bounds handler it means that we only know that the out-of-bounds
2653         case executed at least once. So, for all we know, it may actually be the common case. So,
2654         this patch just deployed the lazy slow path for GC slow paths and masquerades-as-undefined
2655         slow paths. It makes sense for GC slow paths because those have a statistical guarantee of
2656         slow path frequency - probably bounded at less than 1/10. It makes sense for masquerades-as-
2657         undefined because we can say quite confidently that this is an uncommon scenario on the
2658         modern Web.
2659
2660         Something that's always been challenging about abstractions involving the MacroAssembler is
2661         that linking is a separate phase, and there is no way for someone who is just given access to
2662         the MacroAssembler& to emit code that requires linking, since linking happens once we have
2663         emitted all code and we are creating the LinkBuffer. Moreover, the FTL requires that the
2664         final parts of linking happen on the main thread. This patch ran into this issue, and solved
2665         it comprehensively, by introducing MacroAssembler::addLinkTask(). This takes a lambda and
2666         runs it at the bitter end of linking - when performFinalization() is called. This ensure that
2667         the task added by addLinkTask() runs on the main thread. This patch doesn't replace all of
2668         the previously existing idioms for dealing with this issue; we can do that later.
2669
2670         This shows small speed-ups on a bunch of things. No big win on any benchmark aggregate. But
2671         mainly this is done for https://bugs.webkit.org/show_bug.cgi?id=149852, where we found that
2672         outlining the slow path in this way was a significant speed boost.
2673
2674         * CMakeLists.txt:
2675         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2676         * JavaScriptCore.xcodeproj/project.pbxproj:
2677         * assembler/AbstractMacroAssembler.h:
2678         (JSC::AbstractMacroAssembler::replaceWithAddressComputation):
2679         (JSC::AbstractMacroAssembler::addLinkTask):
2680         (JSC::AbstractMacroAssembler::AbstractMacroAssembler):
2681         * assembler/LinkBuffer.cpp:
2682         (JSC::LinkBuffer::linkCode):
2683         (JSC::LinkBuffer::allocate):
2684         (JSC::LinkBuffer::performFinalization):
2685         * assembler/LinkBuffer.h:
2686         (JSC::LinkBuffer::wasAlreadyDisassembled):
2687         (JSC::LinkBuffer::didAlreadyDisassemble):
2688         (JSC::LinkBuffer::vm):
2689         (JSC::LinkBuffer::executableOffsetFor):
2690         * bytecode/CodeOrigin.h:
2691         (JSC::CodeOrigin::CodeOrigin):
2692         (JSC::CodeOrigin::isSet):
2693         (JSC::CodeOrigin::operator bool):
2694         (JSC::CodeOrigin::isHashTableDeletedValue):
2695         (JSC::CodeOrigin::operator!): Deleted.
2696         * ftl/FTLCompile.cpp:
2697         (JSC::FTL::mmAllocateDataSection):
2698         * ftl/FTLInlineCacheDescriptor.h:
2699         (JSC::FTL::InlineCacheDescriptor::InlineCacheDescriptor):
2700         (JSC::FTL::CheckInDescriptor::CheckInDescriptor):
2701         (JSC::FTL::LazySlowPathDescriptor::LazySlowPathDescriptor):
2702         * ftl/FTLJITCode.h:
2703         * ftl/FTLJITFinalizer.cpp:
2704         (JSC::FTL::JITFinalizer::finalizeFunction):
2705         * ftl/FTLJITFinalizer.h:
2706         * ftl/FTLLazySlowPath.cpp: Added.
2707         (JSC::FTL::LazySlowPath::LazySlowPath):
2708         (JSC::FTL::LazySlowPath::~LazySlowPath):
2709         (JSC::FTL::LazySlowPath::generate):
2710         * ftl/FTLLazySlowPath.h: Added.
2711         (JSC::FTL::LazySlowPath::createGenerator):
2712         (JSC::FTL::LazySlowPath::patchpoint):
2713         (JSC::FTL::LazySlowPath::usedRegisters):
2714         (JSC::FTL::LazySlowPath::callSiteIndex):
2715         (JSC::FTL::LazySlowPath::stub):
2716         * ftl/FTLLazySlowPathCall.h: Added.
2717         (JSC::FTL::createLazyCallGenerator):
2718         * ftl/FTLLowerDFGToLLVM.cpp:
2719         (JSC::FTL::DFG::LowerDFGToLLVM::compileCreateActivation):
2720         (JSC::FTL::DFG::LowerDFGToLLVM::compileNewFunction):
2721         (JSC::FTL::DFG::LowerDFGToLLVM::compileCreateDirectArguments):
2722         (JSC::FTL::DFG::LowerDFGToLLVM::compileNewArrayWithSize):
2723         (JSC::FTL::DFG::LowerDFGToLLVM::compileMakeRope):
2724         (JSC::FTL::DFG::LowerDFGToLLVM::compileNotifyWrite):
2725         (JSC::FTL::DFG::LowerDFGToLLVM::compileIsObjectOrNull):
2726         (JSC::FTL::DFG::LowerDFGToLLVM::compileIsFunction):
2727         (JSC::FTL::DFG::LowerDFGToLLVM::compileIn):
2728         (JSC::FTL::DFG::LowerDFGToLLVM::compileMaterializeNewObject):
2729         (JSC::FTL::DFG::LowerDFGToLLVM::compileMaterializeCreateActivation):
2730         (JSC::FTL::DFG::LowerDFGToLLVM::compileCheckWatchdogTimer):
2731         (JSC::FTL::DFG::LowerDFGToLLVM::allocatePropertyStorageWithSizeImpl):
2732         (JSC::FTL::DFG::LowerDFGToLLVM::allocateObject):
2733         (JSC::FTL::DFG::LowerDFGToLLVM::allocateJSArray):
2734         (JSC::FTL::DFG::LowerDFGToLLVM::buildTypeOf):
2735         (JSC::FTL::DFG::LowerDFGToLLVM::sensibleDoubleToInt32):
2736         (JSC::FTL::DFG::LowerDFGToLLVM::lazySlowPath):
2737         (JSC::FTL::DFG::LowerDFGToLLVM::speculate):
2738         (JSC::FTL::DFG::LowerDFGToLLVM::emitStoreBarrier):
2739         * ftl/FTLOperations.cpp:
2740         (JSC::FTL::operationMaterializeObjectInOSR):
2741         (JSC::FTL::compileFTLLazySlowPath):
2742         * ftl/FTLOperations.h:
2743         * ftl/FTLSlowPathCall.cpp:
2744         (JSC::FTL::SlowPathCallContext::SlowPathCallContext):
2745         (JSC::FTL::SlowPathCallContext::~SlowPathCallContext):
2746         (JSC::FTL::SlowPathCallContext::keyWithTarget):
2747         (JSC::FTL::SlowPathCallContext::makeCall):
2748         (JSC::FTL::callSiteIndexForCodeOrigin):
2749         (JSC::FTL::storeCodeOrigin): Deleted.
2750         (JSC::FTL::callOperation): Deleted.
2751         * ftl/FTLSlowPathCall.h:
2752         (JSC::FTL::callOperation):
2753         * ftl/FTLState.h:
2754         * ftl/FTLThunks.cpp:
2755         (JSC::FTL::genericGenerationThunkGenerator):
2756         (JSC::FTL::osrExitGenerationThunkGenerator):
2757         (JSC::FTL::lazySlowPathGenerationThunkGenerator):
2758         (JSC::FTL::registerClobberCheck):
2759         * ftl/FTLThunks.h:
2760         * interpreter/CallFrame.h:
2761         (JSC::CallSiteIndex::CallSiteIndex):
2762         (JSC::CallSiteIndex::operator bool):
2763         (JSC::CallSiteIndex::bits):
2764         * jit/CCallHelpers.h:
2765         (JSC::CCallHelpers::setupArgument):
2766         (JSC::CCallHelpers::setupArgumentsWithExecState):
2767         * jit/JITOperations.cpp:
2768
2769 2015-10-12  Philip Chimento  <philip.chimento@gmail.com>
2770
2771         webkit-gtk-2.3.4 fails to link JavaScriptCore, missing symbols add_history and readline
2772         https://bugs.webkit.org/show_bug.cgi?id=127059
2773
2774         Reviewed by Philippe Normand.
2775
2776         * shell/CMakeLists.txt: Link JSC with -ledit on Mac OSX.
2777
2778 2015-10-11  Yusuke Suzuki  <utatane.tea@gmail.com>
2779
2780         ES6 classes: When a class extends B, super() invokes B.prototype.constructor() instead of B()
2781         https://bugs.webkit.org/show_bug.cgi?id=149001
2782
2783         Reviewed by Saam Barati.
2784
2785         This patch matches the `super()` call in the constructor to the latest spec.
2786         Before this patch, when calling `super()`, it loads `callee.[[HomeObject]].__proto__.constructor`
2787         as a super constructor. But after this patch, it loads `callee.__proto__` as a super constructor.
2788         This behavior corresponds to the section 12.3.5.2[1].
2789
2790         [1]: http://www.ecma-international.org/ecma-262/6.0/#sec-getsuperconstructor
2791
2792         * bytecompiler/NodesCodegen.cpp:
2793         (JSC::SuperNode::emitBytecode):
2794         * tests/stress/super-call-does-not-look-up-constructor.js: Added.
2795         (shouldBe):
2796         (B):
2797         (C):
2798         (B.prototype):
2799
2800 2015-10-10  Andreas Kling  <akling@apple.com>
2801
2802         Reduce pointless malloc traffic in CodeBlock construction.
2803         <https://webkit.org/b/149999>
2804
2805         Reviewed by Antti Koivisto.
2806
2807         Create the RefCountedArray<Instruction> for CodeBlock's m_instructions directly
2808         instead of first creating a Vector<Instruction> and then creating a RefCountedArray
2809         from that. None of the Vector functionality is needed here anyway.
2810
2811         * bytecode/CodeBlock.cpp:
2812         (JSC::CodeBlock::finishCreation):
2813         (JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler):
2814         * bytecode/CodeBlock.h:
2815
2816 2015-10-10  Dan Bernstein  <mitz@apple.com>
2817
2818         [iOS] Remove unnecessary iOS version checks
2819         https://bugs.webkit.org/show_bug.cgi?id=150002
2820
2821         Reviewed by Alexey Proskuryakov.
2822
2823         * llvm/library/LLVMExports.cpp:
2824         (initializeAndGetJSCLLVMAPI):
2825
2826 2015-10-10  Dan Bernstein  <mitz@apple.com>
2827
2828         [iOS] Remove project support for iOS 8
2829         https://bugs.webkit.org/show_bug.cgi?id=149993
2830
2831         Reviewed by Alexey Proskuryakov.
2832
2833         * Configurations/Base.xcconfig:
2834         * Configurations/JSC.xcconfig:
2835         * Configurations/JavaScriptCore.xcconfig:
2836         * Configurations/LLVMForJSC.xcconfig:
2837         * Configurations/ToolExecutable.xcconfig:
2838
2839 2015-10-09  Joseph Pecoraro  <pecoraro@apple.com>
2840
2841         Modernize and cleanup an NSNumber constant
2842         https://bugs.webkit.org/show_bug.cgi?id=149962
2843
2844         Reviewed by Andreas Kling.
2845
2846         * API/JSVirtualMachine.mm:
2847         (-[JSVirtualMachine addExternalRememberedObject:]):
2848
2849 2015-10-09  Joseph Pecoraro  <pecoraro@apple.com>
2850
2851         No need to keep setting needsVisit flag in SmallStrings
2852         https://bugs.webkit.org/show_bug.cgi?id=149961
2853
2854         Reviewed by Andreas Kling.
2855
2856         SmallStrings are all initialized at once privately before the VM
2857         enables Garbage Collection. There is no need to keep updating
2858         this flag, as it couldn't have changed.
2859
2860         * runtime/SmallStrings.cpp:
2861         (JSC::SmallStrings::createEmptyString):
2862         (JSC::SmallStrings::createSingleCharacterString):
2863         (JSC::SmallStrings::initialize):
2864         * runtime/SmallStrings.h:
2865
2866 2015-10-09  Geoffrey Garen  <ggaren@apple.com>
2867
2868         Unreviewed, rolling back in r190694
2869         https://bugs.webkit.org/show_bug.cgi?id=149727
2870
2871         This time for double sure?
2872
2873         The cause of the crash was an incorrect write barrier.
2874
2875         OSR exit was barriering the baseline codeblock for the top of the stack
2876         twice, missing the baseline codeblock for the bottom of the stack.
2877
2878         Restored changesets:
2879
2880         "CodeBlock should be a GC object"
2881         https://bugs.webkit.org/show_bug.cgi?id=149727
2882         http://trac.webkit.org/changeset/r190694
2883
2884 2015-10-09  Joseph Pecoraro  <pecoraro@apple.com>
2885
2886         Remove unused RecursiveAllocationScope
2887         https://bugs.webkit.org/show_bug.cgi?id=149967
2888
2889         Reviewed by Csaba Osztrogonác.
2890
2891         RecursiveAllocationScope has been unused since r163691.
2892
2893         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2894         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2895         * JavaScriptCore.xcodeproj/project.pbxproj:
2896         * heap/Heap.cpp:
2897         * heap/Heap.h:
2898         * heap/RecursiveAllocationScope.h: Removed.
2899         * runtime/VM.h:
2900
2901 2015-10-09  Geoffrey Garen  <ggaren@apple.com>
2902
2903         Unreviewed, rolling out r190694
2904         https://bugs.webkit.org/show_bug.cgi?id=148560
2905
2906         Crashes seen on PLT bots and facebook.com.
2907
2908         Reverted changesets:
2909
2910         "CodeBlock should be a GC object"
2911         https://bugs.webkit.org/show_bug.cgi?id=149727
2912         http://trac.webkit.org/changeset/190694
2913
2914 2015-10-09  Xabier Rodriguez Calvar  <calvaris@igalia.com> and Youenn Fablet  <youenn.fablet@crf.canon.fr>
2915
2916         Automate WebCore JS builtins generation and build system
2917         https://bugs.webkit.org/show_bug.cgi?id=149751
2918
2919         Reviewed by Darin Adler.
2920
2921         * generate-js-builtins: updating the part related to WebCore JS binding.
2922
2923 2015-10-08  Filip Pizlo  <fpizlo@apple.com>
2924
2925         DFG SSA should remove unreachable code
2926         https://bugs.webkit.org/show_bug.cgi?id=149931
2927
2928         Reviewed by Geoffrey Garen.
2929
2930         Rolled back in with a call to m_state.reset(), which fixes the debug asserts.
2931
2932         * dfg/DFGConstantFoldingPhase.cpp:
2933         (JSC::DFG::ConstantFoldingPhase::run): Remove unreachable code.
2934         * dfg/DFGObjectAllocationSinkingPhase.cpp: Deal with the CFG changing.
2935         * dfg/DFGPutStackSinkingPhase.cpp: Deal with the CFG changing.
2936
2937 2015-10-08  Daniel Bates  <dabates@apple.com>
2938
2939         Add LLVM binaries for iOS 9 device
2940         https://bugs.webkit.org/show_bug.cgi?id=149913
2941
2942         Reviewed by Filip Pizlo.
2943
2944         Look for locally built/binary dropped LLVM headers and libraries when building for iOS device
2945         in WebKitBuild/usr/local.
2946
2947         Currently Mac and iOS look for the locally built/binary dropped LLVM in different directories:
2948         WebKitBuild/usr/local and /usr/local/LLVMForJavaScriptCore, respectively. This difference is
2949         due to dependencies with the Apple internal build system. We should look to resolve the
2950         Apple internal dependencies and standardize on one location for both platforms.
2951
2952         * Configurations/Base.xcconfig:
2953
2954 2015-10-08  Commit Queue  <commit-queue@webkit.org>
2955
2956         Unreviewed, rolling out r190749.
2957         https://bugs.webkit.org/show_bug.cgi?id=149938
2958
2959         Caused 50+ layout test failures
2960         https://build.webkit.org/results/Apple%20El%20Capitan%20Debug%20WK1%20(Tests)/r190749%20(213)/results.html
2961         (Requested by litherum1 on #webkit).
2962
2963         Reverted changeset:
2964
2965         "DFG SSA should remove unreachable code"
2966         https://bugs.webkit.org/show_bug.cgi?id=149931
2967         http://trac.webkit.org/changeset/190749
2968
2969 2015-10-08  Filip Pizlo  <fpizlo@apple.com>
2970
2971         DFG SSA should remove unreachable code
2972         https://bugs.webkit.org/show_bug.cgi?id=149931
2973
2974         Reviewed by Geoffrey Garen.
2975
2976         * dfg/DFGConstantFoldingPhase.cpp:
2977         (JSC::DFG::ConstantFoldingPhase::run): Remove unreachable code.
2978         * dfg/DFGObjectAllocationSinkingPhase.cpp: Deal with the CFG changing.
2979         * dfg/DFGPutStackSinkingPhase.cpp: Deal with the CFG changing.
2980
2981 2015-10-08  Joseph Pecoraro  <pecoraro@apple.com>
2982
2983         Unreviewed build fix. Missing forward declaration.
2984
2985         * heap/Heap.h:
2986
2987 2015-10-08  Saam barati  <sbarati@apple.com>
2988
2989         Unreviewed Cloop build fix after bug: https://bugs.webkit.org/show_bug.cgi?id=149601
2990
2991         * bytecode/CodeBlock.cpp:
2992         (JSC::CodeBlock::newExceptionHandlingCallSiteIndex):
2993         * jit/JITCode.cpp:
2994         (JSC::NativeJITCode::addressForCall):
2995         (JSC::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite):
2996         * jit/JITCode.h:
2997
2998 2015-10-08  Joseph Pecoraro  <pecoraro@apple.com>
2999
3000         Clean up Marked classes
3001         https://bugs.webkit.org/show_bug.cgi?id=149853
3002
3003         Reviewed by Darin Adler.
3004
3005         * heap/Heap.h:
3006         Move include here where it is really needed.
3007
3008         * heap/HeapStatistics.cpp:
3009         * heap/HeapStatistics.h:
3010         Simplify includes.
3011
3012         * heap/MarkedAllocator.h:
3013         Add missing copyright header.
3014
3015         * heap/MarkedBlock.cpp:
3016         * heap/MarkedBlock.h:
3017         (JSC::MarkedBlock::needsSweeping):
3018         Remove unused constants. Add some static asserts. Add some `const` ness.
3019
3020         * heap/MarkedSpace.h:
3021         (JSC::MarkedSpace::isIterating):
3022         Update comments to better reflect actual values.
3023         Remove unimplemented method (moved to Heap).
3024
3025         * heap/MarkedSpace.cpp:
3026         (JSC::Free::Free):
3027         (JSC::Free::operator()):
3028         (JSC::Free::returnValue): Deleted.
3029         (JSC::FreeOrShrink::FreeOrShrink):
3030         (JSC::FreeOrShrink::operator()):
3031         (JSC::MarkedSpace::~MarkedSpace):
3032         (JSC::MarkedSpace::shrink):
3033         Replace conditional Functor that was not using return value
3034         with simplified targeted VoidFunctors.
3035
3036         (JSC::Shrink::operator()): Deleted.
3037         Remove unused functor.
3038
3039         * heap/WeakBlock.cpp:
3040         * heap/WeakBlock.h:
3041         * runtime/Options.cpp:
3042         Remove dead code.
3043
3044 2015-10-08  Saam barati  <sbarati@apple.com>
3045
3046         We should be able to inline getter/setter calls inside an inline cache even when the SpillRegistersMode is NeedsToSpill
3047         https://bugs.webkit.org/show_bug.cgi?id=149601
3048
3049         Reviewed by Filip Pizlo.
3050
3051         Before, if we had a PolymorphicAccess with and a StructureStubInfo
3052         with a NeedToSpill spillMode, we wouldn't generate getter/setter
3053         calls. This patch changes it such that we will generate the
3054         getter/setter call and do the necessary register spilling/filling
3055         around the getter/setter call to preserve any "usedRegisters".
3056
3057         This has an interesting story with how it relates to exception handling 
3058         inside the DFG. Because the GetById variants are considered a throwing call 
3059         site, we must make sure that we properly restore the registers spilled to the stack 
3060         in case of an exception being thrown inside the getter/setter call. We do 
3061         this by having the inline cache register itself as a new exception handling 
3062         call site. When the inline cache "catches" the exception (i.e, genericUnwind 
3063         will jump to this code), it will restore the registers it spilled that are 
3064         live inside the original catch handler, and then jump to the original catch 
3065         handler. We make sure to only generate this makeshift catch handler when we 
3066         actually need to do any cleanup. If we determine that we don't need to restore 
3067         any registers, we don't bother generating this makeshift catch handler.
3068
3069         * bytecode/CodeBlock.cpp:
3070         (JSC::CodeBlock::~CodeBlock):
3071         (JSC::CodeBlock::handlerForIndex):
3072         (JSC::CodeBlock::newExceptionHandlingCallSiteIndex):
3073         (JSC::CodeBlock::removeExceptionHandlerForCallSite):
3074         (JSC::CodeBlock::lineNumberForBytecodeOffset):
3075         * bytecode/CodeBlock.h:
3076         (JSC::CodeBlock::appendExceptionHandler):
3077         * bytecode/PolymorphicAccess.cpp:
3078         (JSC::AccessGenerationState::AccessGenerationState):
3079         (JSC::AccessGenerationState::restoreScratch):
3080         (JSC::AccessGenerationState::succeed):
3081         (JSC::AccessGenerationState::calculateLiveRegistersForCallAndExceptionHandling):
3082         (JSC::AccessGenerationState::preserveLiveRegistersToStackForCall):
3083         (JSC::AccessGenerationState::restoreLiveRegistersFromStackForCall):
3084         (JSC::AccessGenerationState::restoreLiveRegistersFromStackForCallWithThrownException):
3085         (JSC::AccessGenerationState::liveRegistersForCall):
3086         (JSC::AccessGenerationState::callSiteIndexForExceptionHandlingOrOriginal):
3087         (JSC::AccessGenerationState::callSiteIndexForExceptionHandling):
3088         (JSC::AccessGenerationState::originalExceptionHandler):
3089         (JSC::AccessGenerationState::numberOfStackBytesUsedForRegisterPreservation):
3090         (JSC::AccessGenerationState::needsToRestoreRegistersIfException):
3091         (JSC::AccessGenerationState::originalCallSiteIndex):
3092         (JSC::AccessGenerationState::liveRegistersToPreserveAtExceptionHandlingCallSite):
3093         (JSC::AccessCase::AccessCase):
3094         (JSC::AccessCase::generate):
3095         (JSC::PolymorphicAccess::regenerateWithCases):
3096         (JSC::PolymorphicAccess::regenerate):
3097         (JSC::PolymorphicAccess::aboutToDie):
3098         * bytecode/PolymorphicAccess.h:
3099         (JSC::AccessCase::doesCalls):
3100         (JSC::AccessCase::isGetter):
3101         (JSC::AccessCase::callLinkInfo):
3102         * bytecode/StructureStubInfo.cpp:
3103         (JSC::StructureStubInfo::deref):
3104         (JSC::StructureStubInfo::aboutToDie):
3105         (JSC::StructureStubInfo::addAccessCase):
3106         * bytecode/StructureStubInfo.h:
3107         * bytecode/ValueRecovery.h:
3108         (JSC::ValueRecovery::isInJSValueRegs):
3109         (JSC::ValueRecovery::fpr):
3110         * dfg/DFGCommonData.cpp:
3111         (JSC::DFG::CommonData::addCodeOrigin):
3112         (JSC::DFG::CommonData::addCodeOriginUnconditionally):
3113         (JSC::DFG::CommonData::lastCallSite):
3114         (JSC::DFG::CommonData::removeCallSiteIndex):
3115         (JSC::DFG::CommonData::shrinkToFit):
3116         * dfg/DFGCommonData.h:
3117         * dfg/DFGJITCode.cpp:
3118         (JSC::DFG::JITCode::reconstruct):
3119         (JSC::DFG::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite):
3120         (JSC::DFG::JITCode::checkIfOptimizationThresholdReached):
3121         * dfg/DFGJITCode.h:
3122         (JSC::DFG::JITCode::osrEntryBlock):
3123         (JSC::DFG::JITCode::setOSREntryBlock):
3124         * dfg/DFGJITCompiler.cpp:
3125         (JSC::DFG::JITCompiler::appendExceptionHandlingOSRExit):
3126         * dfg/DFGOSRExit.cpp:
3127         (JSC::DFG::OSRExit::OSRExit):
3128         * dfg/DFGOSRExit.h:
3129         * dfg/DFGSpeculativeJIT.cpp:
3130         (JSC::DFG::SpeculativeJIT::compileIn):
3131         * dfg/DFGSpeculativeJIT32_64.cpp:
3132         (JSC::DFG::SpeculativeJIT::cachedGetById):
3133         (JSC::DFG::SpeculativeJIT::cachedPutById):
3134         * dfg/DFGSpeculativeJIT64.cpp:
3135         (JSC::DFG::SpeculativeJIT::cachedGetById):
3136         (JSC::DFG::SpeculativeJIT::cachedPutById):
3137         * ftl/FTLCompile.cpp:
3138         (JSC::FTL::mmAllocateDataSection):
3139         * ftl/FTLJITCode.cpp:
3140         (JSC::FTL::JITCode::validateReferences):
3141         (JSC::FTL::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite):
3142         * ftl/FTLJITCode.h:
3143         (JSC::FTL::JITCode::handles):
3144         (JSC::FTL::JITCode::dataSections):
3145         * jit/GCAwareJITStubRoutine.cpp:
3146         (JSC::GCAwareJITStubRoutine::GCAwareJITStubRoutine):
3147         (JSC::GCAwareJITStubRoutine::~GCAwareJITStubRoutine):
3148         (JSC::GCAwareJITStubRoutine::observeZeroRefCount):
3149         (JSC::MarkingGCAwareJITStubRoutineWithOneObject::markRequiredObjectsInternal):
3150         (JSC::GCAwareJITStubRoutineWithExceptionHandler::GCAwareJITStubRoutineWithExceptionHandler):
3151         (JSC::GCAwareJITStubRoutineWithExceptionHandler::aboutToDie):
3152         (JSC::GCAwareJITStubRoutineWithExceptionHandler::~GCAwareJITStubRoutineWithExceptionHandler):
3153         (JSC::createJITStubRoutine):
3154         * jit/GCAwareJITStubRoutine.h:
3155         * jit/JITCode.cpp:
3156         (JSC::NativeJITCode::addressForCall):
3157         (JSC::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite):
3158         * jit/JITCode.h:
3159         * jit/JITInlineCacheGenerator.cpp:
3160         (JSC::JITByIdGenerator::JITByIdGenerator):
3161         (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
3162         (JSC::JITPutByIdGenerator::JITPutByIdGenerator):
3163         * jit/JITInlineCacheGenerator.h:
3164         (JSC::JITByIdGenerator::reportSlowPathCall):
3165         * jit/JITPropertyAccess.cpp:
3166         (JSC::JIT::emitGetByValWithCachedId):
3167         (JSC::JIT::emitPutByValWithCachedId):
3168         (JSC::JIT::emit_op_get_by_id):
3169         (JSC::JIT::emit_op_put_by_id):
3170         * jit/JITPropertyAccess32_64.cpp:
3171         (JSC::JIT::emitGetByValWithCachedId):
3172         (JSC::JIT::emitPutByValWithCachedId):
3173         (JSC::JIT::emit_op_get_by_id):
3174         (JSC::JIT::emit_op_put_by_id):
3175         * jit/JITStubRoutine.h:
3176         (JSC::JITStubRoutine::createSelfManagedRoutine):
3177         (JSC::JITStubRoutine::aboutToDie):
3178         * jit/RegisterSet.cpp:
3179         (JSC::RegisterSet::webAssemblyCalleeSaveRegisters):
3180         (JSC::RegisterSet::registersToNotSaveForCall):
3181         (JSC::RegisterSet::allGPRs):
3182         * jit/RegisterSet.h:
3183         (JSC::RegisterSet::set):
3184         (JSC::RegisterSet::clear):
3185         * jit/ScratchRegisterAllocator.cpp:
3186         (JSC::ScratchRegisterAllocator::allocateScratchGPR):
3187         (JSC::ScratchRegisterAllocator::allocateScratchFPR):
3188         (JSC::ScratchRegisterAllocator::preserveReusedRegistersByPushing):
3189         (JSC::ScratchRegisterAllocator::restoreReusedRegistersByPopping):
3190         (JSC::ScratchRegisterAllocator::usedRegistersForCall):
3191         (JSC::ScratchRegisterAllocator::preserveUsedRegistersToScratchBufferForCall):
3192         (JSC::ScratchRegisterAllocator::restoreUsedRegistersFromScratchBufferForCall):
3193         (JSC::ScratchRegisterAllocator::preserveRegistersToStackForCall):
3194         (JSC::ScratchRegisterAllocator::restoreRegistersFromStackForCall):
3195         * jit/ScratchRegisterAllocator.h:
3196         (JSC::ScratchRegisterAllocator::numberOfReusedRegisters):
3197         (JSC::ScratchRegisterAllocator::usedRegisters):
3198         * jsc.cpp:
3199         (WTF::CustomGetter::CustomGetter):
3200         (WTF::CustomGetter::createStructure):
3201         (WTF::CustomGetter::create):
3202         (WTF::CustomGetter::getOwnPropertySlot):
3203         (WTF::CustomGetter::customGetter):
3204         (WTF::Element::handleOwner):
3205         (GlobalObject::finishCreation):
3206         (functionCreateImpureGetter):
3207         (functionCreateCustomGetterObject):
3208         (functionSetImpureGetterDelegate):
3209         * tests/stress/try-catch-custom-getter-as-get-by-id.js: Added.
3210         (assert):
3211         (bar):
3212         (foo):
3213         * tests/stress/try-catch-getter-as-get-by-id-register-restoration.js: Added.
3214         (assert):
3215         (o1.get f):
3216         (bar):
3217         (foo):
3218         * tests/stress/try-catch-getter-as-get-by-id.js: Added.
3219         (assert):
3220         (o1.get f):
3221         (bar):
3222         (foo):
3223         * tests/stress/try-catch-setter-as-put-by-id.js: Added.
3224         (assert):
3225         (o1.set f):
3226         (bar):
3227         (foo):
3228         * tests/stress/try-catch-stub-routine-replaced.js: Added.
3229         (assert):
3230         (arr):
3231         (hello):
3232         (foo):
3233         (objChain.get f):
3234         (fakeOut.get f):
3235         (o.get f):
3236
3237 2015-10-08  Commit Queue  <commit-queue@webkit.org>
3238
3239         Unreviewed, rolling out r190716.
3240         https://bugs.webkit.org/show_bug.cgi?id=149924
3241
3242         broke mac build from time to time (Requested by youenn on
3243         #webkit).
3244
3245         Reverted changeset:
3246
3247         "Automate WebCore JS builtins generation and build system"
3248         https://bugs.webkit.org/show_bug.cgi?id=149751
3249         http://trac.webkit.org/changeset/190716
3250
3251 2015-10-08  Csaba Osztrogonác  <ossy@webkit.org>
3252
3253         Fix the WASM build on Linux
3254         https://bugs.webkit.org/show_bug.cgi?id=149919
3255
3256         Reviewed by Mark Lam.
3257
3258         * inspector/ScriptCallStackFactory.cpp:
3259         * wasm/JSWASMModule.cpp:
3260         * wasm/WASMFunctionCompiler.h:
3261         (JSC::sizeOfMemoryType):
3262         * wasm/WASMFunctionLLVMIRGenerator.h:
3263
3264 2015-10-08  Csaba Osztrogonác  <ossy@webkit.org>
3265
3266         Unreviewed CLOOP buildfix after r190718.
3267
3268         * jit/Repatch.h:
3269         (JSC::resetGetByID): Deleted.
3270         (JSC::resetPutByID): Deleted.
3271         (JSC::resetIn): Deleted.
3272
3273 2015-10-08  Joseph Pecoraro  <pecoraro@apple.com>
3274
3275         Remove references to removed class RepatchBuffer
3276         https://bugs.webkit.org/show_bug.cgi?id=149909
3277
3278         Reviewed by Csaba Osztrogonác.
3279
3280         * assembler/AbstractMacroAssembler.h:
3281         * assembler/MacroAssemblerARM.h:
3282         * assembler/MacroAssemblerARM64.h:
3283         * assembler/MacroAssemblerARMv7.h:
3284         * assembler/MacroAssemblerMIPS.h:
3285         * assembler/MacroAssemblerSH4.h:
3286         * assembler/MacroAssemblerX86.h:
3287         * assembler/MacroAssemblerX86_64.h:
3288         * jit/JITStubRoutine.h:
3289         * jit/Repatch.h:
3290
3291 2015-10-08  Xabier Rodriguez Calvar  <calvaris@igalia.com> and Youenn Fablet  <youenn.fablet@crf.canon.fr>
3292
3293         Automate WebCore JS builtins generation and build system
3294         https://bugs.webkit.org/show_bug.cgi?id=149751
3295
3296         Reviewed by Darin Adler.
3297
3298         * generate-js-builtins: updating the part related to WebCore JS binding.
3299
3300 2015-10-07  Joseph Pecoraro  <pecoraro@apple.com>
3301
3302         Clean up Copied classes
3303         https://bugs.webkit.org/show_bug.cgi?id=149863
3304
3305         Reviewed by Saam Barati.
3306
3307         * heap/CopiedAllocator.h:
3308         (JSC::CopiedAllocator::isValid):
3309         * heap/CopiedBlock.h:
3310         * heap/CopiedBlockInlines.h:
3311         * heap/CopiedSpace.cpp:
3312         * heap/CopiedSpace.h:
3313         (JSC::CopiedSpace::isInCopyPhase):
3314         (JSC::CopiedSpace::shouldDoCopyPhase):
3315         * heap/CopiedSpaceInlines.h:
3316         * heap/CopyToken.h:
3317         * heap/CopyVisitor.cpp:
3318         * heap/CopyVisitor.h:
3319         * heap/CopyVisitorInlines.h:
3320         * heap/CopyWorkList.h:
3321         * heap/HandleBlock.h:
3322         * heap/HandleSet.h:
3323         * heap/HeapHelperPool.cpp:
3324         * heap/HeapHelperPool.h:
3325
3326 2015-10-07  Mark Lam  <mark.lam@apple.com>
3327
3328         [Follow up 2] Disable tail calls because it is breaking some sites.
3329         https://bugs.webkit.org/show_bug.cgi?id=149900
3330
3331         Rubber stamped by Saam Barati.
3332
3333         Also need to surpress JSC tail call tests.
3334
3335         * tests/es6.yaml:
3336         * tests/stress/dfg-tail-calls.js:
3337         (nonInlinedTailCall.callee):
3338         * tests/stress/mutual-tail-call-no-stack-overflow.js:
3339         (shouldThrow):
3340         * tests/stress/tail-call-in-inline-cache.js:
3341         (tail):
3342         * tests/stress/tail-call-no-stack-overflow.js:
3343         (shouldThrow):
3344         * tests/stress/tail-call-recognize.js:
3345         (callerMustBeRun):
3346         * tests/stress/tail-call-varargs-no-stack-overflow.js:
3347         (shouldThrow):
3348
3349 2015-10-07  Geoffrey Garen  <ggaren@apple.com>
3350
3351         Unreviewed, rolling back in r190450
3352         https://bugs.webkit.org/show_bug.cgi?id=149727
3353
3354         This time for sure?
3355
3356         The cause of the leak was an invalidated compilation.
3357
3358         There was vestigial manual memory management code that eagerly removed
3359         a CodeBlock from the set of CodeBlocks if compilation was invalidated.
3360         That's not cool since we rely on the set of CodeBlocks when we run
3361         destructors.
3362
3363         The fix is to remove the vestigial code.
3364
3365         I ran the leaks, correctness, and performance tests locally and did not
3366         see any problems.
3367
3368         Restored changesets:
3369
3370         "CodeBlock should be a GC object"
3371         https://bugs.webkit.org/show_bug.cgi?id=149727
3372         http://trac.webkit.org/changeset/190450
3373
3374 2015-10-07  Mark Lam  <mark.lam@apple.com>
3375
3376         Disable tail calls because it is breaking some sites.
3377         https://bugs.webkit.org/show_bug.cgi?id=149900
3378
3379         Reviewed by Saam Barati.
3380
3381         This is until we fix whatever the breakage is.
3382
3383         * runtime/Options.h:
3384
3385 2015-10-07  Sukolsak Sakshuwong  <sukolsak@gmail.com>
3386
3387         Add an LLVM IR generator for WebAssembly
3388         https://bugs.webkit.org/show_bug.cgi?id=149486
3389
3390         Reviewed by Mark Lam.
3391
3392         This patch adds initial support for an LLVM IR generator in WebAssembly
3393         (polyfill-prototype-1 format). All the methods will be implemented in
3394         subsequent patches.
3395
3396         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
3397         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
3398         * JavaScriptCore.xcodeproj/project.pbxproj:
3399         * wasm/WASMFunctionLLVMIRGenerator.h: Added.
3400         (JSC::WASMFunctionLLVMIRGenerator::MemoryAddress::MemoryAddress):
3401         (JSC::WASMFunctionLLVMIRGenerator::startFunction):
3402         (JSC::WASMFunctionLLVMIRGenerator::endFunction):
3403         (JSC::WASMFunctionLLVMIRGenerator::buildSetLocal):
3404         (JSC::WASMFunctionLLVMIRGenerator::buildSetGlobal):
3405         (JSC::WASMFunctionLLVMIRGenerator::buildReturn):
3406         (JSC::WASMFunctionLLVMIRGenerator::buildImmediateI32):
3407         (JSC::WASMFunctionLLVMIRGenerator::buildImmediateF32):
3408         (JSC::WASMFunctionLLVMIRGenerator::buildImmediateF64):
3409         (JSC::WASMFunctionLLVMIRGenerator::buildGetLocal):
3410         (JSC::WASMFunctionLLVMIRGenerator::buildGetGlobal):
3411         (JSC::WASMFunctionLLVMIRGenerator::buildConvertType):
3412         (JSC::WASMFunctionLLVMIRGenerator::buildLoad):
3413         (JSC::WASMFunctionLLVMIRGenerator::buildStore):
3414         (JSC::WASMFunctionLLVMIRGenerator::buildUnaryI32):
3415         (JSC::WASMFunctionLLVMIRGenerator::buildUnaryF32):
3416         (JSC::WASMFunctionLLVMIRGenerator::buildUnaryF64):
3417         (JSC::WASMFunctionLLVMIRGenerator::buildBinaryI32):
3418         (JSC::WASMFunctionLLVMIRGenerator::buildBinaryF32):
3419         (JSC::WASMFunctionLLVMIRGenerator::buildBinaryF64):
3420         (JSC::WASMFunctionLLVMIRGenerator::buildRelationalI32):
3421         (JSC::WASMFunctionLLVMIRGenerator::buildRelationalF32):
3422         (JSC::WASMFunctionLLVMIRGenerator::buildRelationalF64):
3423         (JSC::WASMFunctionLLVMIRGenerator::buildMinOrMaxI32):
3424         (JSC::WASMFunctionLLVMIRGenerator::buildMinOrMaxF64):
3425         (JSC::WASMFunctionLLVMIRGenerator::buildCallInternal):
3426         (JSC::WASMFunctionLLVMIRGenerator::buildCallIndirect):
3427         (JSC::WASMFunctionLLVMIRGenerator::buildCallImport):
3428         (JSC::WASMFunctionLLVMIRGenerator::appendExpressionList):
3429         (JSC::WASMFunctionLLVMIRGenerator::discard):
3430         (JSC::WASMFunctionLLVMIRGenerator::linkTarget):
3431         (JSC::WASMFunctionLLVMIRGenerator::jumpToTarget):
3432         (JSC::WASMFunctionLLVMIRGenerator::jumpToTargetIf):
3433         (JSC::WASMFunctionLLVMIRGenerator::startLoop):
3434         (JSC::WASMFunctionLLVMIRGenerator::endLoop):
3435         (JSC::WASMFunctionLLVMIRGenerator::startSwitch):
3436         (JSC::WASMFunctionLLVMIRGenerator::endSwitch):
3437         (JSC::WASMFunctionLLVMIRGenerator::startLabel):
3438         (JSC::WASMFunctionLLVMIRGenerator::endLabel):
3439         (JSC::WASMFunctionLLVMIRGenerator::breakTarget):
3440         (JSC::WASMFunctionLLVMIRGenerator::continueTarget):
3441         (JSC::WASMFunctionLLVMIRGenerator::breakLabelTarget):
3442         (JSC::WASMFunctionLLVMIRGenerator::continueLabelTarget):
3443         (JSC::WASMFunctionLLVMIRGenerator::buildSwitch):
3444         * wasm/WASMFunctionParser.cpp:
3445
3446 2015-10-07  Filip Pizlo  <fpizlo@apple.com>
3447
3448         Get rid of LLInt inline/out-of-line storage helpers, they are unused
3449         https://bugs.webkit.org/show_bug.cgi?id=149892
3450
3451         Reviewed by Mark Lam.
3452
3453         Just killing dead code.
3454
3455         * llint/LowLevelInterpreter.asm:
3456
3457 2015-10-07  Filip Pizlo  <fpizlo@apple.com>
3458
3459         Don't setOutOfBounds in JIT code for PutByVal, since the C++ slow path already does it
3460         https://bugs.webkit.org/show_bug.cgi?id=149885
3461
3462         Reviewed by Geoffrey Garen.
3463
3464         This simplifies the slow path code, which will make it easier to put read barriers on all of
3465         the butterflies.
3466
3467         * jit/JITOperations.cpp:
3468         (JSC::getByVal):
3469         * jit/JITPropertyAccess.cpp:
3470         (JSC::JIT::emitSlow_op_put_by_val):
3471
3472 2015-10-07  Filip Pizlo  <fpizlo@apple.com>
3473
3474         Get rid of JIT::compilePutDirectOffset
3475         https://bugs.webkit.org/show_bug.cgi?id=149884
3476
3477         Reviewed by Andreas Kling.
3478
3479         I'm finding more dead code.
3480
3481         * jit/JIT.h:
3482         * jit/JITPropertyAccess.cpp:
3483         (JSC::JIT::emitSlow_op_put_by_id):
3484         (JSC::JIT::emitVarInjectionCheck):
3485         (JSC::JIT::compilePutDirectOffset): Deleted.
3486
3487 2015-10-07  Joseph Pecoraro  <pecoraro@apple.com>
3488
3489         Heap::isWriteBarrierEnabled is unused
3490         https://bugs.webkit.org/show_bug.cgi?id=149881
3491
3492         Reviewed by Geoffrey Garen.
3493
3494         * heap/Heap.h:
3495         * heap/HeapInlines.h:
3496         (JSC::Heap::isWriteBarrierEnabled): Deleted.
3497
3498 2015-10-07  Filip Pizlo  <fpizlo@apple.com>
3499
3500         JIT::emitGetGlobalProperty/emitPutGlobalProperty are only called from one place
3501         https://bugs.webkit.org/show_bug.cgi?id=149879
3502
3503         Reviewed by Saam Barati.
3504
3505         To simplify my work to insert barriers on loads of the butterfly, I want to reduce the amount
3506         of abstraction we have around code that loads the butterfly.
3507
3508         * jit/JIT.h:
3509         * jit/JITPropertyAccess.cpp:
3510         (JSC::JIT::emitLoadWithStructureCheck):
3511         (JSC::JIT::emitGetVarFromPointer):
3512         (JSC::JIT::emit_op_get_from_scope):
3513         (JSC::JIT::emitSlow_op_get_from_scope):
3514         (JSC::JIT::emitPutGlobalVariable):
3515         (JSC::JIT::emit_op_put_to_scope):
3516         (JSC::JIT::emitGetGlobalProperty): Deleted.
3517         (JSC::JIT::emitPutGlobalProperty): Deleted.
3518         * jit/JITPropertyAccess32_64.cpp:
3519         (JSC::JIT::emitLoadWithStructureCheck):
3520         (JSC::JIT::emitGetVarFromPointer):
3521         (JSC::JIT::emit_op_get_from_scope):
3522         (JSC::JIT::emitSlow_op_get_from_scope):
3523         (JSC::JIT::emitPutGlobalVariable):
3524         (JSC::JIT::emit_op_put_to_scope):
3525         (JSC::JIT::emitGetGlobalProperty): Deleted.
3526         (JSC::JIT::emitPutGlobalProperty): Deleted.
3527
3528 2015-10-07  Filip Pizlo  <fpizlo@apple.com>
3529
3530         JIT::compileGetDirectOffset is useless
3531         https://bugs.webkit.org/show_bug.cgi?id=149878
3532
3533         Reviewed by Mark Lam.
3534
3535         Two of the overloads of this method were never called. The other was called only from one
3536         place, in a manner that rendered most of its code dead. This change removes the dead code and
3537         folds the method into its one caller.
3538
3539         * jit/JIT.h:
3540         * jit/JITPropertyAccess.cpp:
3541         (JSC::JIT::emitSlow_op_get_by_val):
3542         (JSC::JIT::emit_op_put_by_val):
3543         (JSC::JIT::compilePutDirectOffset):
3544         (JSC::JIT::emitVarInjectionCheck):
3545         (JSC::JIT::emitGetGlobalProperty):
3546         (JSC::JIT::emitGetVarFromPointer):
3547         (JSC::JIT::compileGetDirectOffset): Deleted.
3548         * jit/JITPropertyAccess32_64.cpp:
3549         (JSC::JIT::compilePutDirectOffset):
3550         (JSC::JIT::emitVarInjectionCheck):
3551         (JSC::JIT::emitGetGlobalProperty):
3552         (JSC::JIT::emitGetVarFromPointer):
3553         (JSC::JIT::compileGetDirectOffset): Deleted.
3554
3555 2015-10-06  Filip Pizlo  <fpizlo@apple.com>
3556
3557         Inline caches should handle out-of-line offsets out-of-line
3558         https://bugs.webkit.org/show_bug.cgi?id=149869
3559
3560         Reviewed by Saam Barati.
3561
3562         If we want to have a concurrent copying GC, then we need a read barrier on copied space
3563         pointers. That makes the convertible load portion of the get_by_id/put_by_id inline caches
3564         rather challenging. Currently we have a load instruction that we can turn into an add
3565         instruction - the add case is when we have an inline offset, and the load case is when we
3566         have an out-of-line offset and we need to load a copied space pointer. But if the load from
3567         copied space requires a barrier, then there is no easy way to convert that back to the inline
3568         case.
3569
3570         This patch removes the convertible load. The inline path of get_by_id/put_by_id only handles
3571         the inline offsets. Out-of-line offsets are now handled using out-of-line stubs.
3572
3573         * bytecode/StructureStubInfo.h:
3574         * ftl/FTLInlineCacheSize.cpp:
3575         (JSC::FTL::sizeOfGetById):
3576         (JSC::FTL::sizeOfPutById):
3577         * jit/JITInlineCacheGenerator.cpp:
3578         (JSC::JITByIdGenerator::finalize):
3579         (JSC::JITByIdGenerator::generateFastPathChecks):
3580         (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
3581         (JSC::JITGetByIdGenerator::generateFastPath):
3582         (JSC::JITPutByIdGenerator::JITPutByIdGenerator):
3583         (JSC::JITPutByIdGenerator::generateFastPath):
3584         * jit/JITInlineCacheGenerator.h:
3585         * jit/Repatch.cpp:
3586         (JSC::repatchByIdSelfAccess):
3587         (JSC::tryCacheGetByID):
3588         (JSC::tryCachePutByID):
3589         * runtime/JSObject.h:
3590         (JSC::JSObject::butterflyTotalSize):
3591         (JSC::indexRelativeToBase):
3592         (JSC::offsetRelativeToBase):
3593         (JSC::maxOffsetRelativeToBase):
3594         (JSC::makeIdentifier):
3595         (JSC::offsetRelativeToPatchedStorage): Deleted.
3596         (JSC::maxOffsetRelativeToPatchedStorage): Deleted.
3597
3598 2015-10-07  Commit Queue  <commit-queue@webkit.org>
3599
3600         Unreviewed, rolling out r190664.
3601         https://bugs.webkit.org/show_bug.cgi?id=149877
3602
3603         mac build is sometimes borken due to missing generated header
3604         file (Requested by youenn on #webkit).
3605
3606         Reverted changeset:
3607
3608         "Automate WebCore JS builtins generation and build system"
3609         https://bugs.webkit.org/show_bug.cgi?id=149751
3610         http://trac.webkit.org/changeset/190664
3611
3612 2015-10-07  Xabier Rodriguez Calvar  <calvaris@igalia.com> and Youenn Fablet  <youenn.fablet@crf.canon.fr>
3613
3614         Automate WebCore JS builtins generation and build system
3615         https://bugs.webkit.org/show_bug.cgi?id=149751
3616
3617         Reviewed by Darin Adler.
3618
3619         * generate-js-builtins: updating the part related to WebCore JS binding.
3620
3621 2015-10-06  Mark Lam  <mark.lam@apple.com>
3622
3623         Factoring out op_sub baseline code generation into JITSubGenerator.
3624         https://bugs.webkit.org/show_bug.cgi?id=149600
3625
3626         Reviewed by Geoffrey Garen.
3627
3628         We're going to factor out baseline code generation into snippet generators so
3629         that we can later use them in the DFG and FTL to emit code for to perform the
3630         JS operations where the operand types are predicted to be polymorphic.
3631         We are starting in this patch with the implementation of op_sub.
3632
3633         What was done in this patch:
3634         1. Created JITSubGenerator based on the baseline implementation of op_sub as
3635            expressed in compileBinaryArithOp() and compileBinaryArithOpSlowCase().
3636            I did not attempt to do write a more optimal version of op_sub.  I'll
3637            leave that to a later patch.
3638
3639         2. Convert the 32-bit op_sub baseline implementation to use the same
3640            JITSubGenerator which was based on the 64-bit implementation.  The
3641            pre-existing 32-bit baseline op_sub had handling for more optimization cases.
3642            However, a benchmark run shows that simply going with the 64-bit version
3643            (foregoing those extra optimizations) did not change the performance.
3644
3645            Also, previously, the 32-bit version was able to move double results directly
3646            into the result location on the stack directly.  By using JITSubGenerator,
3647            we now always move that result into a pair of GPRs before storing it into
3648            the stack location.
3649
3650         3. Add some needed emitters to AssemblyHelpers that play nice with JSValueRegs.
3651
3652         * JavaScriptCore.xcodeproj/project.pbxproj:
3653         * jit/AssemblyHelpers.h:
3654         (JSC::AssemblyHelpers::boxDouble):
3655         (JSC::AssemblyHelpers::unboxDouble):
3656         (JSC::AssemblyHelpers::boxBooleanPayload):
3657         * jit/JIT.h:
3658         (JSC::JIT::linkDummySlowCase):
3659         * jit/JITArithmetic.cpp:
3660         (JSC::JIT::compileBinaryArithOp):
3661         (JSC::JIT::compileBinaryArithOpSlowCase):
3662         (JSC::JIT::emitSlow_op_div):
3663         (JSC::JIT::emit_op_sub):
3664         (JSC::JIT::emitSlow_op_sub):
3665         * jit/JITArithmetic32_64.cpp:
3666         (JSC::JIT::emitBinaryDoubleOp):
3667         (JSC::JIT::emit_op_sub): Deleted.
3668         (JSC::JIT::emitSub32Constant): Deleted.
3669         (JSC::JIT::emitSlow_op_sub): Deleted.
3670         * jit/JITInlines.h:
3671         (JSC::JIT::linkSlowCaseIfNotJSCell):
3672         (JSC::JIT::linkAllSlowCasesForBytecodeOffset):
3673         (JSC::JIT::addSlowCase):
3674         (JSC::JIT::emitLoad):
3675         (JSC::JIT::emitGetVirtualRegister):
3676         (JSC::JIT::emitPutVirtualRegister):
3677         * jit/JITSubGenerator.h: Added.
3678         (JSC::JITSubGenerator::JITSubGenerator):
3679         (JSC::JITSubGenerator::generateFastPath):
3680         (JSC::JITSubGenerator::slowPathJumpList):
3681
3682 2015-10-06  Daniel Bates  <dbates@webkit.org>
3683
3684         Enable XSLT when building WebKit for iOS using the public iOS SDK
3685         https://bugs.webkit.org/show_bug.cgi?id=149827
3686
3687         Reviewed by Alexey Proskuryakov.
3688
3689         * Configurations/FeatureDefines.xcconfig:
3690
3691 2015-10-05  Commit Queue  <commit-queue@webkit.org>
3692
3693         Unreviewed, rolling out r190599.
3694         https://bugs.webkit.org/show_bug.cgi?id=149836
3695
3696         Made perf tests randomly crash (Requested by ap on #webkit).
3697
3698         Reverted changeset:
3699
3700         "GC shouldn't cancel every FTL compilation"
3701         https://bugs.webkit.org/show_bug.cgi?id=149821
3702         http://trac.webkit.org/changeset/190599
3703
3704 2015-10-05  Commit Queue  <commit-queue@webkit.org>
3705
3706         Unreviewed, rolling out r190589.
3707         https://bugs.webkit.org/show_bug.cgi?id=149833
3708
3709         Caused lots of leaks, and possibly crashes (Requested by ap on
3710         #webkit).
3711
3712         Reverted changeset:
3713
3714         "Unreviewed, rolling back in r190450"
3715         https://bugs.webkit.org/show_bug.cgi?id=149727
3716         http://trac.webkit.org/changeset/190589
3717
3718 2015-10-05  Geoffrey Garen  <ggaren@apple.com>
3719
3720         Remove a few includes from JSGlobalObject.h
3721         https://bugs.webkit.org/show_bug.cgi?id=148004
3722
3723         Reviewed by Saam Barati.
3724
3725         * parser/VariableEnvironment.cpp:
3726         * parser/VariableEnvironment.h:
3727         * runtime/JSGlobalObject.h:
3728         * runtime/JSString.cpp:
3729         (JSC::JSString::createStructure):
3730         (JSC::JSRopeString::RopeBuilder::expand):
3731         * runtime/JSString.h:
3732         (JSC::JSString::canGetIndex):
3733         (JSC::JSString::offsetOfLength):
3734         (JSC::JSString::offsetOfFlags):
3735         (JSC::JSString::createStructure): Deleted.
3736         * runtime/Structure.h:
3737         * runtime/StructureInlines.h:
3738         * runtime/StructureRareDataInlines.h:
3739
3740 2015-10-05  Filip Pizlo  <fpizlo@apple.com>
3741
3742         GC shouldn't cancel every FTL compilation
3743         https://bugs.webkit.org/show_bug.cgi?id=149821
3744
3745         Reviewed by Saam Barati.
3746
3747         During one of the CodeBlock GC refactorings, we messed up the GC's compilation cancellation
3748         code. The GC should be able to cancel compilation plans if it determines that the plan will
3749         be DOA. But, prior to this fix, that code was killing every FTL compilation. This happened
3750         because the meaning of CodeBlock::isKnownToBeLiveDuringGC() changed.
3751
3752         It's funny that this didn't show up as a bigger slow-down. Basically, those benchmarks that
3753         GC a lot usually don't rely on good compilation, while those benchmarks that do rely on good
3754         compilation usually don't GC a lot. That's probably why this wasn't super obvious when we
3755         broke it.
3756
3757         This change just changes the cancellation logic so that it only cancels plans if the owning
3758         executable is dead. This is safe; in fact the relevant method would be correct even if it
3759         always returned true. It would also be correct if it always returned false. So, compared to
3760         what we had before we changed isKnownToBeLiveDuringGC(), this new code will cancel fewer
3761         compilations. But, that's better than cancelling every compilation. I've filed a bug and
3762         written a FIXME for investigating ways to resurrect the old behavior:
3763         https://bugs.webkit.org/show_bug.cgi?id=149823
3764
3765         Nonetheless, this change looks like it might be a 1% speed-up on Octane. It improves earley
3766         and gbemu.
3767
3768         * dfg/DFGPlan.cpp:
3769         (JSC::DFG::Plan::isKnownToBeLiveDuringGC):
3770
3771 2015-10-05  Sukolsak Sakshuwong  <sukolsak@gmail.com>
3772
3773         [Intl] Change the return type of canonicalizeLocaleList() from JSArray* to Vector<String>
3774         https://bugs.webkit.org/show_bug.cgi?id=149807
3775
3776         Reviewed by Benjamin Poulain.
3777
3778         From ECMA-402, 9.2.1, the abstract operation CanonicalizeLocaleList
3779         returns a List of Strings. From the spec, we never modify the result
3780         from CanonicalizeLocaleList(). We never expose it to the user either.
3781         This patch changes the return type of canonicalizeLocaleList() from
3782         JSArray* to Vector<String>. This should ease the workload of the GC and
3783         make the code a bit easier to read.
3784
3785         * runtime/IntlCollatorConstructor.cpp:
3786         (JSC::IntlCollatorConstructorFuncSupportedLocalesOf):
3787         * runtime/IntlDateTimeFormatConstructor.cpp:
3788         (JSC::IntlDateTimeFormatConstructorFuncSupportedLocalesOf):
3789         * runtime/IntlNumberFormatConstructor.cpp:
3790         (JSC::IntlNumberFormatConstructorFuncSupportedLocalesOf):
3791         * runtime/IntlObject.cpp:
3792         (JSC::canonicalizeLocaleList):
3793         (JSC::lookupSupportedLocales):
3794         (JSC::bestFitSupportedLocales):
3795         (JSC::supportedLocales):
3796         * runtime/IntlObject.h:
3797
3798 2015-10-01  Geoffrey Garen  <ggaren@apple.com>
3799
3800         Unreviewed, rolling back in r190450
3801         https://bugs.webkit.org/show_bug.cgi?id=149727
3802
3803         The cause of the leak was VM shutdown, which happens in workers.
3804
3805         The fix is for CodeBlockSet to participate in lastChanceToFinalize,
3806         since it's responsible for running CodeBlock destructors.
3807
3808         I ran the leaks tests locally and did not see any CodeBlock-related leaks.
3809
3810         Restored changesets:
3811
3812         "CodeBlock should be a GC object"
3813         https://bugs.webkit.org/show_bug.cgi?id=149727
3814         http://trac.webkit.org/changeset/190450
3815
3816 2015-10-03  Filip Pizlo  <fpizlo@apple.com>
3817
3818         Allow an object's marking state to track The Three Colors
3819         https://bugs.webkit.org/show_bug.cgi?id=149654
3820
3821         Reviewed by Geoffrey Garen.
3822
3823         I want to make GC marking concurrent (see https://bugs.webkit.org/show_bug.cgi?id=149432).
3824         Concurrent GC require barriers to be executed during certain heap operations. We already have a
3825         generational GC. Generational GCs also need barriers, and we already have those. The generational
3826         GC barrier that we use is the "sticky mark bit" barrier. Ordinarily, mark bits get reset after a
3827         collection. In our collector, there is a secondary mark bit that "sticks" - i.e. it does not get
3828         reset. If the sticky mark bit is set in between two collections, then we know that the object is in
3829         old space. This is sufficient to determine when to put things into remembered sets. Additionally,
3830         the sticky mark bit is actually a tri-state that can also tell us if the object has been placed on
3831         a remembered set.
3832
3833         This is awfully similar to what you want in a concurrent GC. Concurrent GCs typically want writes
3834         to the heap that change the object graph to do different things depending on an object's marking
3835         state, which is usually referred to as its color. White means that the object has never been seen
3836         by the collector. All white objects are presumed dead at the flip. Grey objects are those that are
3837         known to the collector but have not been scanned. Black objects are those that have been scanned,
3838         and will not be scanned again. White is exactly just "not being marked", and both grey and black
3839         mean "marked" - with "black" meaning "marked but not on any worklist". That's quite a bit like the
3840         current "Marked" and "MarkedAndRemembered" states that we have for generational GC.
3841         "MarkedAndRemembered" is a lot like "grey", and "Marked" is a lot like "black".
3842
3843         I want to make a concurrent GC that unifies the generational and concurrent barriers into a single
3844         fast path check. Even better if the two barriers are entirely identical. You can do this using
3845         Pirinen's technique #2 [1], originally due to Guy Steele [2]: when doing o.f=v where o is black and
3846         v is white, turn o grey again. This is like remembering an object, in the sense that our gen GC
3847         "rememberes" o when o is old and v is new. It remembers objects by putting them on the mark stack,
3848         setting the generational state to MarkedAndRemembered, and doing nothing to the primary mark bit.
3849
3850         This makes our concurrent GC approach pretty obvious. We want to use one barrier for concurrent and
3851         generational, and we want to basically keep our current barriers unchanged. The only things missing
3852         are just some small changes to allow the concurrent GC to know precisely when an object is black,
3853         and to know during object visiting if we are visiting the object for the first time during a
3854         collection or a subsequent time due to barrier re-greying (concurrent GC) or barrier remembering
3855         (generational GC). So, this patch does the following:
3856
3857         - Changes the terminology used for the gcData header byte in JSCell. This changes the name of this
3858           to cellState, and introduces a new enumeration called CellState. This new enumeration behaves a
3859           lot like the old GCData did. It has the following members, with the following correspondence to
3860           the old GCData:
3861
3862           OldBlack: this is like Marked, with the exception that we ensure that an object becomes OldBlack
3863               as soon as the object starts to be scanned. Previously, an object might be
3864               MarkedAndRemembered during scanning and we'd turn all MarkedAndRemembered objects into Marked
3865               objects during a post-processing step at the end of GC. This patch gets rid of that
3866               post-processing. The act of visiting an object unconditionally makes it OldBlack. Note that
3867               our definition of "black" is not that the object is done being scanned, but that it is either
3868               being scanned right now or it has already been scanned. This is like a combination of
3869               Siebert's anthracite and black states [3].
3870
3871           NewWhite: this is exactly NotMarked. It's the state that objects get when they are allocated.
3872               It's impossible for an object to return to this state.
3873
3874           OldGrey: the object is on the mark stack and will be scanned at some point in the future. This
3875               also means that this isn't the first time in this cycle that the object has been grey. In an
3876               eden collection, an old object that has been remembered is thought of as being OldGrey, even
3877               if this is the first time during this eden collection that it is grey. That's because an eden
3878               collection must behave "as if" the grey->black transition for old objects magically happened
3879               at the start of GC. Remembered objects are like old objects that underwent a concurrent
3880               barrier re-greying just after the magical old object grey->black transition at the start of
3881               GC. This state is almost exactly like MarkedAndRemembered, except that an object now
3882               transitions from OldGrey to OldBlack at the beginning of visiting, rather than how previously
3883               we transitioned from MarkedAndRemembered to Marked at the bitter end of GC.
3884
3885           NewGray: the object is on the mark stack and will be scanned at some point in the future. This
3886               state has no clear relative in the old state system. It means that the object became grey due
3887               to ordinary marking. Previously, ordinary marking would make the object Marked.
3888
3889         - Removal of the post-processing phase that "clears" the remembered set by moving all remembered
3890           objects to the Marked state. This now happens magically during visiting, as described above.
3891
3892         - SlotVisitor now remembers the state that the object did have just before visiting. While visiting
3893           that object, it's possible to query what the state was. This is used for copy space decisions and
3894           for extra memory usage accounting. We don't want to put the backing store on the copy worklist,
3895           and we don't want to count extra memory usage, if the object was OldGrey at the start of
3896           visiting. Previously, we would be able to just ask if the object was MarkedAndRemembered since
3897           that state wouldn't get cleared until after all marking finished. This change also simplifies
3898           some APIs, because there is no need to pass the JSCell* pointer, since these SlotVisitor methods
3899           no longer ask the cell for its state - instead they use the saved pre-visiting state.
3900
3901         - Removal of a bunch of helpers and abstractions. Previously we had various methods for asking if
3902           an object was "marked" and if an object was "remembered". We had helpers for adjusting these
3903           states, and those helpers would assert that they were being used the right way. This is not very