Timeline

Jul 22, 2018:

5:40 PM Changeset in webkit [234092] by Nikita Vasilyev

• 2 edits in trunk/Source/WebInspectorUI

Web Inspector: Dark Mode: remove odd-looking top border
​https://bugs.webkit.org/show_bug.cgi?id=187885

Reviewed by Matt Baker.

This border doesn't exist in the light mode, and it shouldn't be in the dark mode either.

• UserInterface/Views/DarkMode.css:

(@media (prefers-dark-interface)):
(body .toolbar):

12:48 PM Changeset in webkit [234091] by Alan Bujtas

• 4 edits in trunk/Source/WebCore

[LFC][IFC] Add center/right/justify line alignment support.
​https://bugs.webkit.org/show_bug.cgi?id=187890

Reviewed by Antti Koivisto.

Move over some more code from simple line layout.
(though text-align: justify is more preformant as now expansion opportunities are added as we process the text runs
-as opposed to iterting through the runs again when we reach the end of the line.)

• layout/inlineformatting/textlayout/Runs.h:

(WebCore::Layout::LayoutRun::setLeft):
(WebCore::Layout::LayoutRun::setExpansion):

• layout/inlineformatting/textlayout/simple/SimpleLineBreaker.cpp:

(WebCore::Layout::SimpleLineBreaker::Line::Line):
(WebCore::Layout::SimpleLineBreaker::Line::setTextAlign):
(WebCore::Layout::SimpleLineBreaker::Line::adjustedLeftForTextAlign const):
(WebCore::Layout::SimpleLineBreaker::Line::justifyRuns):
(WebCore::Layout::SimpleLineBreaker::Line::adjustRunsForTextAlign):
(WebCore::Layout::expansionOpportunity):
(WebCore::Layout::expansionBehavior):
(WebCore::Layout::SimpleLineBreaker::Line::collectExpansionOpportunities):
(WebCore::Layout::SimpleLineBreaker::Line::closeLastRun):
(WebCore::Layout::SimpleLineBreaker::Line::append):
(WebCore::Layout::SimpleLineBreaker::Line::collapseTrailingWhitespace):
(WebCore::Layout::SimpleLineBreaker::Line::reset):
(WebCore::Layout::SimpleLineBreaker::Style::Style):
(WebCore::Layout::SimpleLineBreaker::handleLineEnd):
(WebCore::Layout::SimpleLineBreaker::handleLineStart):
(WebCore::Layout::isTextAlignRight):
(WebCore::Layout::SimpleLineBreaker::createRunsForLine):

• layout/inlineformatting/textlayout/simple/SimpleLineBreaker.h:

(WebCore::Layout::SimpleLineBreaker::Line::setAvailableWidth):
(WebCore::Layout::SimpleLineBreaker::Line::setCollapseWhitespace):

12:24 PM Changeset in webkit [234090] by Yusuke Suzuki

• 4 edits
  2 adds in trunk

[JSC] GetByIdVariant and InByIdVariant do not need slot base if they are not "hit" variants
​https://bugs.webkit.org/show_bug.cgi?id=187891

Reviewed by Saam Barati.

JSTests:

• stress/in-miss-variant-merge.js: Added.

(shouldBe):
(test):

• stress/miss-variant-merge.js: Added.

(shouldBe):
(test):

Source/JavaScriptCore:

When merging GetByIdVariant and InByIdVariant, we accidentally make merging failed if
two variants are mergeable but they have "Miss" status. We make merging failed if
the merged OPCSet says hasOneSlotBaseCondition() is false. But it is only reasonable
if the variant has "Hit" status. This bug is revealed when we introduce CreateThis in FTL,
which patch have more chances to merge variants.

This patch fixes this issue by checking !isPropertyUnset() / isHit(). PutByIdVariant
is not related since it does not use this check in Transition case.

• bytecode/GetByIdVariant.cpp:

(JSC::GetByIdVariant::attemptToMerge):

• bytecode/InByIdVariant.cpp:

(JSC::InByIdVariant::attemptToMerge):

9:54 AM Changeset in webkit [234089] by Yusuke Suzuki

• 8 edits
  3 adds in trunk

[DFG] Fold GetByVal if the indexed value is non configurable and non writable
​https://bugs.webkit.org/show_bug.cgi?id=186462

Reviewed by Saam Barati.

JSTests:

• stress/folding-get-by-val-with-read-only-dont-delete-object.js: Added.

(shouldBe):
(test1):
(test2):
(test3):
(test4):
(test5):

• stress/folding-get-by-val-with-read-only-dont-delete-runtime-array.js: Added.

(shouldBe):
(test1):
(test2):
(test5):

• stress/folding-get-by-val-with-read-only-dont-delete.js: Added.

(shouldBe):
(test1):
(test2):
(test3):
(test4):
(test5):

Source/JavaScriptCore:

Non-special DontDelete | ReadOnly properties mean that it won't be changed. If DFG AI can retrieve this
property, AI can fold it into a constant. This type of property can be seen when we use ES6 tagged templates.
Tagged templates' callsite includes indexed properties whose attributes are DontDelete | ReadOnly.

This patch attempts to fold such properties into constant in DFG AI. The challenge is that DFG AI runs
concurrently with the mutator thread. In this patch, we insert WTF::storeStoreFence between value setting
and attributes setting. The attributes must be set after the corresponding value is set. If the loaded
attributes (with WTF::loadLoadFence) include DontDelete | ReadOnly, it means the given value won't be
changed and we can safely use it. We arrange our existing code to use this protocol.

Since GetByVal folding requires the correct Structure & Butterfly pairs, it is only enabled in x86 architecture
since it is TSO. So, our WTF::storeStoreFence in SparseArrayValueMap is also emitted only in x86.

This patch improves SixSpeed/template_string_tag.es6.

baseline patched

template_string_tag.es6 237.0301+-4.8374 ^{9.8779+-0.3628} definitely 23.9960x faster

• dfg/DFGAbstractInterpreterInlines.h:

(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):

• runtime/JSArray.cpp:

(JSC::JSArray::setLengthWithArrayStorage):

• runtime/JSObject.cpp:

(JSC::JSObject::enterDictionaryIndexingModeWhenArrayStorageAlreadyExists):
(JSC::JSObject::deletePropertyByIndex):
(JSC::JSObject::getOwnPropertyNames):
(JSC::putIndexedDescriptor):
(JSC::JSObject::defineOwnIndexedProperty):
(JSC::JSObject::attemptToInterceptPutByIndexOnHoleForPrototype):
(JSC::JSObject::putIndexedDescriptor): Deleted.

• runtime/JSObject.h:
• runtime/SparseArrayValueMap.cpp:

(JSC::SparseArrayValueMap::SparseArrayValueMap):
(JSC::SparseArrayValueMap::add):
(JSC::SparseArrayValueMap::putDirect):
(JSC::SparseArrayValueMap::getConcurrently):
(JSC::SparseArrayEntry::get const):
(JSC::SparseArrayEntry::getConcurrently const):
(JSC::SparseArrayEntry::put):
(JSC::SparseArrayEntry::getNonSparseMode const):
(JSC::SparseArrayValueMap::visitChildren):
(JSC::SparseArrayValueMap::~SparseArrayValueMap): Deleted.

• runtime/SparseArrayValueMap.h:

(JSC::SparseArrayEntry::SparseArrayEntry):
(JSC::SparseArrayEntry::attributes const):
(JSC::SparseArrayEntry::forceSet):
(JSC::SparseArrayEntry::asValue):

Jul 21, 2018:

9:56 PM Changeset in webkit [234088] by Simon Fraser

• 4 edits in trunk/Tools

Fix lldb summarizers for HashMaps and HashSets
​https://bugs.webkit.org/show_bug.cgi?id=187883

Reviewed by Dan Bates.

HashMap and HashSet summarizers were broken in various ways.

The 'type summary add -x' regexp needs to match at the start and end of the string
to avoid finding types nested inside other templates.

The HashTable synthetic child code incorrectly used the type of the key, rather than
the value when synthesizing children.

Add HashMap and HashSet summarizers.

I tried to get synthetic children working directly for HashMap and HashSet, but was unable.

• lldb/lldbWebKitTester/main.cpp:

(testSummaryProviders):

• lldb/lldb_webkit.py:

(lldb_init_module):
(lldb_init_module.lldb_webkit):
(WTFHashMap_SummaryProvider):
(WTFHashSet_SummaryProvider):
(WebCoreColorProvider._to_string_extended):
(WebCoreURLProvider.to_string):
(WTFHashMapProvider):
(WTFHashMapProvider.init):
(WTFHashMapProvider.tableSize):
(WTFHashMapProvider.keyCount):
(WTFHashSetProvider):
(WTFHashSetProvider.init):
(WTFHashSetProvider.tableSize):
(WTFHashSetProvider.keyCount):
(WTFHashTableProvider.tableSize):
(WTFHashTableProvider):
(WTFHashTableProvider.keyCount):
(WTFHashTableProvider.get_child_at_index):
(WTFHashTableProvider.update):

• lldb/lldb_webkit_unittest.py:

(TestSummaryProviders.serial_test_WTFVectorProvider_empty_vector):
(TestSummaryProviders.serial_test_WTFVectorProvider_vector_size_and_capacity):
(TestSummaryProviders):
(TestSummaryProviders.serial_test_WTFHashMap_tablesize_and_size):
(TestSummaryProviders.serial_test_WTFHashMap_of_vectors_tablesize_and_size):
(TestSummaryProviders.serial_test_WTFHashSet_tablesize_and_size):

9:09 PM Changeset in webkit [234087] by Simon Fraser

• 2 edits in trunk/Tools

Add lldb formatters for WebCore geometry types
​https://bugs.webkit.org/show_bug.cgi?id=187884

Reviewed by Daniel Bates.

Add lldb formatters for IntPoint, IntSize, IntRect, FloatPoint, FloatSize, FloatRect
and LayoutRect.

Testing is blocked by webkit.org/b/187872.

• lldb/lldbWebKitTester/main.cpp:

(testSummaryProviders):

• lldb/lldb_webkit.py:

(lldb_init_module.lldb_webkit):
(lldb_init_module):
(WebCoreLayoutRect_SummaryProvider):
(WebCoreIntSize_SummaryProvider):
(WebCoreIntPoint_SummaryProvider):
(WebCoreFloatSize_SummaryProvider):
(WebCoreFloatPoint_SummaryProvider):
(WebCoreIntRect_SummaryProvider):
(WebCoreFloatRect_SummaryProvider):
(WebCoreLayoutRectProvider):
(WebCoreLayoutRectProvider.init):
(WebCoreLayoutRectProvider.get_x):
(WebCoreLayoutRectProvider.get_y):
(WebCoreLayoutRectProvider.get_width):
(WebCoreLayoutRectProvider.get_height):
(WebCoreIntPointProvider):
(WebCoreIntPointProvider.init):
(WebCoreIntPointProvider.get_x):
(WebCoreIntPointProvider.get_y):
(WebCoreIntSizeProvider):
(WebCoreIntSizeProvider.init):
(WebCoreIntSizeProvider.get_width):
(WebCoreIntSizeProvider.get_height):
(WebCoreIntRectProvider):
(WebCoreIntRectProvider.init):
(WebCoreIntRectProvider.get_x):
(WebCoreIntRectProvider.get_y):
(WebCoreIntRectProvider.get_width):
(WebCoreIntRectProvider.get_height):
(WebCoreFloatPointProvider):
(WebCoreFloatPointProvider.init):
(WebCoreFloatPointProvider.get_x):
(WebCoreFloatPointProvider.get_y):
(WebCoreFloatSizeProvider):
(WebCoreFloatSizeProvider.init):
(WebCoreFloatSizeProvider.get_width):
(WebCoreFloatSizeProvider.get_height):
(WebCoreFloatRectProvider):
(WebCoreFloatRectProvider.init):
(WebCoreFloatRectProvider.get_x):
(WebCoreFloatRectProvider.get_y):
(WebCoreFloatRectProvider.get_width):
(WebCoreFloatRectProvider.get_height):

7:48 PM Changeset in webkit [234086] by fpizlo@apple.com

• 79 edits
  14 adds in trunk

We should support CreateThis in the FTL
​https://bugs.webkit.org/show_bug.cgi?id=164904

Reviewed by Yusuke Suzuki.
JSTests:

• microbenchmarks/polyvariant-get-by-id-shorter-tower.js: Added.

(polyvariant):
(Foo.prototype.func):
(Foo):
(foo):
(Bar.prototype.func):
(Bar):
(bar):

• microbenchmarks/polyvariant-get-by-id-tower.js: Added.

(polyvariant):
(Foo.prototype.func):
(Foo):
(foo):
(Bar.prototype.func):
(Bar):
(bar):
(Baz.prototype.func):
(Baz):
(baz):

Source/JavaScriptCore:

This started with Saam's patch to implement CreateThis in the FTL, but turned into a type
inference adventure.

CreateThis in the FTL was a massive regression in raytrace because it disturbed that
benchmark's extremely perverse way of winning at type inference:

• The benchmark wanted polyvariant devirtualization of an object construction helper. But, the polyvariant profiler wasn't powerful enough to reliably devirtualize that code. So, the benchmark was falling back to other mechanisms...

• The construction helper could not tier up into the FTL. When the DFG compiled it, it would see that the IC had 4 cases. That's too polymorphic for the DFG. So, the DFG would emit a GetById. Shortly after the DFG compile, that get_by_id would see many more cases, but now that the helper was compiled by the DFG, the baseline get_by_id would not see those cases. The DFG's GetById would "hide" those cases. The number of cases the DFG's GetById would see is larger than our polymorphic list limit (limit = 8, case count = 13, I think).

Note that if the FTL compiles that construction helper, it sees the 4 cases, turns them
into a MultiGetByOffset, then suffers from exits when the new cases hit, and then exits to
baseline, which then sees those cases. Luckily, the FTL was not compiling the construction
helper because it had a CreateThis.

• Compilations that inlined the construction helper would have gotten super lucky with parse-time constant folding, so they knew what structure the input to the get_by_id would have at parse time. This is only profitable if the get_by_id parsing computed a GetByIdStatus that had a finite number of cases. Because the 13 cases were being hidden by the DFG GetById and GetByIdStatus would only look at the baseline get_by_id, which had 4 cases, we would indeed get a finite number of cases. The parser would then prune those cases to just one - based on its knowledge of the structure - and that would result in that get_by_id being folded at parse time to a constant.

• The subsequent op_call would inline based on parse-time knowledge of that constant.

This patch comprehensively fixes these issues, as well as other issues that come up along the
way. The short version is that raytrace was revealing sloppiness in our use of profiling for
type inference. This patch fixes the sloppiness by vastly expanding *polyvariant* profiling,
i.e. the profiling that considers call context. I was encouraged to do this by the fact that
even the old version of polyvariant profiling was a speed-up on JetStream, ARES-6, and
Speedometer 2 (it's easy to measure since it's a runtime flag). So, it seemed worthwhile to
attack raytrace's problem as a shortcoming of polyvariant profiling.

• Polyvariant profiling now consults every DFG or FTL code block that participated in any subset of the inline stack that includes the IC we're profiling. For example, if we have an inline stack like foo->bar->baz, with baz on top, then we will consult DFG or FTL compilations for foo, bar, and baz. In foo, we'll look up foo->bar->baz; in bar we'll look up bar->baz; etc. This fixes two problems encountered in raytrace. First, it ensures that a DFG GetById cannot hide anything from the profiling of that get_by_id, since the polyvariant profiling code will always consult it. Second, it enables raytrace to benefit from polyvariant profling. Previously, the polyvariant profiler would only look at the previous DFG compilation of foo and look up foo->bar->baz. But that only works if DFG-foo had inlined bar and then baz. It may not have done that, because those calls could have required polyvariant profiling that was only available in the FTL.

• A particularly interesting case is when some IC in foo-baseline is also available in foo-DFG. This case is encountered by the polyvariant profiler as it walks the inline stack. In the case of gathering profiling for foo-FTL, the polyvariant profiler finds foo-DFG via the trivial case of no inline stack. This also means that if foo ever gets inlined, we will find foo-DFG or foo-FTL in the final case of polyvariant profiling. In those cases, we now merge the IC of foo-baseline and foo-DFG. This avoids lots of unnecessary recompilations, because it warns us of historical polymorphism. Historical polymorphism usually means future polymorphism. IC status code already had some merging functionality, but I needed to beef it up a lot to make this work right.

• Inlining an inline cache now preserves as much information as profiling. One challenge of polyvariant profiling is that the FTL compile for bar (that includes bar->baz) could have inlined an inline cache based on polyvariant profiling. So, when the FTL compile for foo (that includes foo->bar->baz) asks bar what it knows about that IC inside bar->baz, it will say "I don't have such an IC". At this point the DFG compilation that included that IC that gave us the information that we used to inline the IC is no longer alive. To keep us from losing the information we learned about the IC, there is now a RecordedStatuses data structure that preserves the statuses we use for inlining ICs. We also filter those statuses according to things we learn from AI. This further reduces the risk of information about an IC being forgotten.

• Exit profiling now considers whether or not an exit happened from inline code. This protects us in the case where the not-inlined version of an IC exited a lot because of polymorphism that doesn't exist in the inlined version. So, when using polyvariant profiling data, we consider only inlined exits.

• CallLinkInfo now records when it's repatched to the virtual call thunk. Previously, this would clear the CallLinkInfo, so CallLinkStatus would fall back to the lastSeenCallee. It's surprising that we've had this bug.

Altogether this patch is performance-neutral in run-jsc-benchmarks, except for speed-ups in
microbenchmarks and a compile time regression. Octane/deltablue speeds up by ~5%.
Octane/raytrace is regressed by a minuscule amount, which we could make up by implementing
prototype access folding in the bytecode parser and constant folder. That would require some
significant new logic in GetByIdStatus. That would also require a new benchmark - we want to
have a test that captures raytrace's behavior in the case that the parser cannot fold the
get_by_id.

This change is a 1.2% regression on V8Spider-CompileTime. That's a smaller regression than
recent compile time progressions, so I think that's an OK trade-off. Also, I would expect a
compile time regression anytime we fill in FTL coverage.

This is neutral on JetStream, ARES-6, and Speedometer2. JetStream agrees that deltablue
speeds up and that raytrace slows down, but these changes balance out and don't affect the
overall score. In ARES-6, it looks like individual tests have some significant 1-2% speed-ups
or slow-downs. Air-steady is definitely ~1.5% faster. Basic-worst is probably 2% slower (p ~
0.1, so it's not very certain). The JetStream, ARES-6, and Speedometer2 overall scores don't
see a significant difference. In all three cases the difference is <0.5% with a high p value,
with JetStream and Speedometer2 being insignificant infinitesimal speed-ups and ARES-6 being
an insignificant infinitesimal slow-down.

Oh, and this change means that the FTL now has 100% coverage of JavaScript. You could do an
eval in a for-in loop in a for-of loop inside a with block that uses try/catch for control
flow in a polymorphic constructor while having a bad time, and we'll still compile it.

• CMakeLists.txt:
• JavaScriptCore.xcodeproj/project.pbxproj:
• Sources.txt:
• bytecode/ByValInfo.h:
• bytecode/BytecodeDumper.cpp:

(JSC::BytecodeDumper<Block>::printGetByIdCacheStatus):
(JSC::BytecodeDumper<Block>::printPutByIdCacheStatus):
(JSC::BytecodeDumper<Block>::printInByIdCacheStatus):
(JSC::BytecodeDumper<Block>::dumpCallLinkStatus):
(JSC::BytecodeDumper<CodeBlock>::dumpCallLinkStatus):
(JSC::BytecodeDumper<Block>::printCallOp):
(JSC::BytecodeDumper<Block>::dumpBytecode):
(JSC::BytecodeDumper<Block>::dumpBlock):

• bytecode/BytecodeDumper.h:
• bytecode/CallLinkInfo.h:
• bytecode/CallLinkStatus.cpp:

(JSC::CallLinkStatus::computeFor):
(JSC::CallLinkStatus::computeExitSiteData):
(JSC::CallLinkStatus::computeFromCallLinkInfo):
(JSC::CallLinkStatus::accountForExits):
(JSC::CallLinkStatus::finalize):
(JSC::CallLinkStatus::filter):
(JSC::CallLinkStatus::computeDFGStatuses): Deleted.

• bytecode/CallLinkStatus.h:

(JSC::CallLinkStatus::operator bool const):
(JSC::CallLinkStatus::operator! const): Deleted.

• bytecode/CallVariant.cpp:

(JSC::CallVariant::finalize):
(JSC::CallVariant::filter):

• bytecode/CallVariant.h:

(JSC::CallVariant::operator bool const):
(JSC::CallVariant::operator! const): Deleted.

• bytecode/CodeBlock.cpp:

(JSC::CodeBlock::dumpBytecode):
(JSC::CodeBlock::propagateTransitions):
(JSC::CodeBlock::finalizeUnconditionally):
(JSC::CodeBlock::getICStatusMap):
(JSC::CodeBlock::resetJITData):
(JSC::CodeBlock::getStubInfoMap): Deleted.
(JSC::CodeBlock::getCallLinkInfoMap): Deleted.
(JSC::CodeBlock::getByValInfoMap): Deleted.

• bytecode/CodeBlock.h:
• bytecode/CodeOrigin.cpp:

(JSC::CodeOrigin::isApproximatelyEqualTo const):
(JSC::CodeOrigin::approximateHash const):

• bytecode/CodeOrigin.h:

(JSC::CodeOrigin::exitingInlineKind const):

• bytecode/DFGExitProfile.cpp:

(JSC::DFG::FrequentExitSite::dump const):
(JSC::DFG::ExitProfile::add):

• bytecode/DFGExitProfile.h:

(JSC::DFG::FrequentExitSite::FrequentExitSite):
(JSC::DFG::FrequentExitSite::operator== const):
(JSC::DFG::FrequentExitSite::subsumes const):
(JSC::DFG::FrequentExitSite::hash const):
(JSC::DFG::FrequentExitSite::inlineKind const):
(JSC::DFG::FrequentExitSite::withInlineKind const):
(JSC::DFG::QueryableExitProfile::hasExitSite const):
(JSC::DFG::QueryableExitProfile::hasExitSiteWithSpecificJITType const):
(JSC::DFG::QueryableExitProfile::hasExitSiteWithSpecificInlineKind const):

• bytecode/ExitFlag.cpp: Added.

(JSC::ExitFlag::dump const):

• bytecode/ExitFlag.h: Added.

(JSC::ExitFlag::ExitFlag):
(JSC::ExitFlag::operator| const):
(JSC::ExitFlag::operator|=):
(JSC::ExitFlag::operator& const):
(JSC::ExitFlag::operator&=):
(JSC::ExitFlag::operator bool const):
(JSC::ExitFlag::isSet const):

• bytecode/ExitingInlineKind.cpp: Added.

(WTF::printInternal):

• bytecode/ExitingInlineKind.h: Added.
• bytecode/GetByIdStatus.cpp:

(JSC::GetByIdStatus::computeFor):
(JSC::GetByIdStatus::computeForStubInfo):
(JSC::GetByIdStatus::slowVersion const):
(JSC::GetByIdStatus::markIfCheap):
(JSC::GetByIdStatus::finalize):
(JSC::GetByIdStatus::hasExitSite): Deleted.

• bytecode/GetByIdStatus.h:
• bytecode/GetByIdVariant.cpp:

(JSC::GetByIdVariant::markIfCheap):
(JSC::GetByIdVariant::finalize):

• bytecode/GetByIdVariant.h:
• bytecode/ICStatusMap.cpp: Added.

(JSC::ICStatusContext::get const):
(JSC::ICStatusContext::isInlined const):
(JSC::ICStatusContext::inlineKind const):

• bytecode/ICStatusMap.h: Added.
• bytecode/ICStatusUtils.cpp: Added.

(JSC::hasBadCacheExitSite):

• bytecode/ICStatusUtils.h:
• bytecode/InstanceOfStatus.cpp:

(JSC::InstanceOfStatus::computeFor):

• bytecode/InstanceOfStatus.h:
• bytecode/PolyProtoAccessChain.h:
• bytecode/PutByIdStatus.cpp:

(JSC::PutByIdStatus::hasExitSite):
(JSC::PutByIdStatus::computeFor):
(JSC::PutByIdStatus::slowVersion const):
(JSC::PutByIdStatus::markIfCheap):
(JSC::PutByIdStatus::finalize):
(JSC::PutByIdStatus::filter):

• bytecode/PutByIdStatus.h:
• bytecode/PutByIdVariant.cpp:

(JSC::PutByIdVariant::markIfCheap):
(JSC::PutByIdVariant::finalize):

• bytecode/PutByIdVariant.h:

(JSC::PutByIdVariant::structureSet const):

• bytecode/RecordedStatuses.cpp: Added.

(JSC::RecordedStatuses::operator=):
(JSC::RecordedStatuses::RecordedStatuses):
(JSC::RecordedStatuses::addCallLinkStatus):
(JSC::RecordedStatuses::addGetByIdStatus):
(JSC::RecordedStatuses::addPutByIdStatus):
(JSC::RecordedStatuses::markIfCheap):
(JSC::RecordedStatuses::finalizeWithoutDeleting):
(JSC::RecordedStatuses::finalize):
(JSC::RecordedStatuses::shrinkToFit):

• bytecode/RecordedStatuses.h: Added.

(JSC::RecordedStatuses::RecordedStatuses):
(JSC::RecordedStatuses::forEachVector):

• bytecode/StructureSet.cpp:

(JSC::StructureSet::markIfCheap const):
(JSC::StructureSet::isStillAlive const):

• bytecode/StructureSet.h:
• bytecode/TerminatedCodeOrigin.h: Added.

(JSC::TerminatedCodeOrigin::TerminatedCodeOrigin):
(JSC::TerminatedCodeOriginHashTranslator::hash):
(JSC::TerminatedCodeOriginHashTranslator::equal):

• bytecode/Watchpoint.cpp:

(WTF::printInternal):

• bytecode/Watchpoint.h:
• dfg/DFGAbstractInterpreter.h:
• dfg/DFGAbstractInterpreterInlines.h:

(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
(JSC::DFG::AbstractInterpreter<AbstractStateType>::filterICStatus):

• dfg/DFGByteCodeParser.cpp:

(JSC::DFG::ByteCodeParser::handleCall):
(JSC::DFG::ByteCodeParser::handleVarargsCall):
(JSC::DFG::ByteCodeParser::handleDOMJITGetter):
(JSC::DFG::ByteCodeParser::handleModuleNamespaceLoad):
(JSC::DFG::ByteCodeParser::handleGetById):
(JSC::DFG::ByteCodeParser::handlePutById):
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
(JSC::DFG::ByteCodeParser::InlineStackEntry::~InlineStackEntry):
(JSC::DFG::ByteCodeParser::parse):

• dfg/DFGClobberize.h:

(JSC::DFG::clobberize):

• dfg/DFGClobbersExitState.cpp:

(JSC::DFG::clobbersExitState):

• dfg/DFGCommonData.h:
• dfg/DFGConstantFoldingPhase.cpp:

(JSC::DFG::ConstantFoldingPhase::foldConstants):

• dfg/DFGDesiredWatchpoints.h:

(JSC::DFG::SetPointerAdaptor::hasBeenInvalidated):

• dfg/DFGDoesGC.cpp:

(JSC::DFG::doesGC):

• dfg/DFGFixupPhase.cpp:

(JSC::DFG::FixupPhase::fixupNode):

• dfg/DFGGraph.cpp:

(JSC::DFG::Graph::dump):

• dfg/DFGMayExit.cpp:
• dfg/DFGNode.h:

(JSC::DFG::Node::hasCallLinkStatus):
(JSC::DFG::Node::callLinkStatus):
(JSC::DFG::Node::hasGetByIdStatus):
(JSC::DFG::Node::getByIdStatus):
(JSC::DFG::Node::hasPutByIdStatus):
(JSC::DFG::Node::putByIdStatus):

• dfg/DFGNodeType.h:
• dfg/DFGOSRExitBase.cpp:

(JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSiteSlow):

• dfg/DFGObjectAllocationSinkingPhase.cpp:
• dfg/DFGPlan.cpp:

(JSC::DFG::Plan::reallyAdd):
(JSC::DFG::Plan::checkLivenessAndVisitChildren):
(JSC::DFG::Plan::finalizeInGC):

• dfg/DFGPlan.h:
• dfg/DFGPredictionPropagationPhase.cpp:
• dfg/DFGSafeToExecute.h:

(JSC::DFG::safeToExecute):

• dfg/DFGSpeculativeJIT32_64.cpp:

(JSC::DFG::SpeculativeJIT::compile):

• dfg/DFGSpeculativeJIT64.cpp:

(JSC::DFG::SpeculativeJIT::compile):

• dfg/DFGStrengthReductionPhase.cpp:

(JSC::DFG::StrengthReductionPhase::handleNode):

• dfg/DFGWorklist.cpp:

(JSC::DFG::Worklist::removeDeadPlans):

• ftl/FTLAbstractHeapRepository.h:
• ftl/FTLCapabilities.cpp:

(JSC::FTL::canCompile):

• ftl/FTLLowerDFGToB3.cpp:

(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileCreateThis):
(JSC::FTL::DFG::LowerDFGToB3::compileFilterICStatus):

• jit/PolymorphicCallStubRoutine.cpp:

(JSC::PolymorphicCallStubRoutine::hasEdges const):
(JSC::PolymorphicCallStubRoutine::edges const):

• jit/PolymorphicCallStubRoutine.h:
• profiler/ProfilerBytecodeSequence.cpp:

(JSC::Profiler::BytecodeSequence::BytecodeSequence):

• runtime/FunctionRareData.cpp:

(JSC::FunctionRareData::initializeObjectAllocationProfile):

• runtime/Options.h:

Source/WTF:

• wtf/TinyPtrSet.h:

(WTF::TinyPtrSet::operator!= const):

4:28 PM lldb formatters edited by Simon Fraser

(diff)

4:27 PM lldb formatters edited by Simon Fraser

(diff)

4:23 PM lldb formatters created by Simon Fraser

4:21 PM WikiStart edited by Simon Fraser

(diff)

11:49 AM Changeset in webkit [234085] by Alan Bujtas

• 5 edits in trunk/Source/WebCore

[LFC][IFC] Add verification for inline text runs.
​https://bugs.webkit.org/show_bug.cgi?id=187879

Reviewed by Antti Koivisto.

• layout/Verification.cpp:

(WebCore::Layout::outputMismatchingSimpleLineInformationIfNeeded):
(WebCore::Layout::outputMismatchingComplexLineInformationIfNeeded):
(WebCore::Layout::outputMismatchingBlockBoxInformationIfNeeded):
(WebCore::Layout::verifyAndOutputSubtree):
(WebCore::Layout::outputMismatchingBoxInformationIfNeeded): Deleted.

• layout/inlineformatting/InlineFormattingContext.cpp:

(WebCore::Layout::InlineFormattingContext::layout const):

• layout/inlineformatting/InlineFormattingState.h:

(WebCore::Layout::InlineFormattingState::addLayoutRuns):
(WebCore::Layout::InlineFormattingState::layoutRuns const):

• layout/layouttree/LayoutTreeBuilder.cpp:

(WebCore::Layout::outputLayoutBox):
(WebCore::Layout::outputLayoutTree):
(WebCore::Layout::TreeBuilder::showLayoutTree):

11:47 AM Changeset in webkit [234084] by Alan Bujtas

• 9 edits in trunk/Source/WebCore

[LFC] Do not use virtual methods to construct floating/formatting states.
​https://bugs.webkit.org/show_bug.cgi?id=187875

Reviewed by Antti Koivisto.

LayoutContext::establishedFormattingState() does not require FormattingContext anymore only the root of the context.

• layout/FormattingContext.cpp:

(WebCore::Layout::FormattingContext::layoutOutOfFlowDescendants const):

• layout/FormattingContext.h:
• layout/LayoutContext.cpp:

(WebCore::Layout::LayoutContext::layoutFormattingContextSubtree):
(WebCore::Layout::LayoutContext::formattingStateForBox const):
(WebCore::Layout::LayoutContext::establishedFormattingState):

• layout/LayoutContext.h:
• layout/blockformatting/BlockFormattingContext.cpp:

(WebCore::Layout::BlockFormattingContext::layoutFormattingContextRoot const):
(WebCore::Layout::BlockFormattingContext::instrinsicWidthConstraints const):
(WebCore::Layout::BlockFormattingContext::createFormattingState const): Deleted.
(WebCore::Layout::BlockFormattingContext::createOrFindFloatingState const): Deleted.

• layout/blockformatting/BlockFormattingContext.h:
• layout/inlineformatting/InlineFormattingContext.cpp:

(WebCore::Layout::InlineFormattingContext::createFormattingState const): Deleted.
(WebCore::Layout::InlineFormattingContext::createOrFindFloatingState const): Deleted.

• layout/inlineformatting/InlineFormattingContext.h:

8:00 AM Changeset in webkit [234083] by Alan Bujtas

• 4 edits in trunk/Source/WebCore

[LFC][BFC] Do not collapse top/bottom margin with first/last inflow child from a non-block formatting context.
​https://bugs.webkit.org/show_bug.cgi?id=187867

Reviewed by Antti Koivisto.

The box's top/bottom margin never collapses with a non-block inflow child.

• layout/blockformatting/BlockMarginCollapse.cpp:

(WebCore::Layout::isMarginTopCollapsedWithSibling):
(WebCore::Layout::isMarginBottomCollapsedWithSibling):
(WebCore::Layout::isMarginTopCollapsedWithParent):
(WebCore::Layout::isMarginBottomCollapsedThrough):
(WebCore::Layout::BlockFormattingContext::MarginCollapse::collapsedMarginTopFromFirstChild):
(WebCore::Layout::BlockFormattingContext::MarginCollapse::nonCollapsedMarginTop):
(WebCore::Layout::BlockFormattingContext::MarginCollapse::computedNonCollapsedMarginTop):
(WebCore::Layout::BlockFormattingContext::MarginCollapse::computedNonCollapsedMarginBottom):
(WebCore::Layout::BlockFormattingContext::MarginCollapse::marginTop):
(WebCore::Layout::BlockFormattingContext::MarginCollapse::marginBottom):
(WebCore::Layout::BlockFormattingContext::MarginCollapse::isMarginBottomCollapsedWithParent):
(WebCore::Layout::BlockFormattingContext::MarginCollapse::collapsedMarginBottomFromLastChild):
(WebCore::Layout::BlockFormattingContext::MarginCollapse::nonCollapsedMarginBottom):

• layout/layouttree/LayoutBox.cpp:

(WebCore::Layout::Box::establishesBlockFormattingContextOnly const): <div style="overflow: hidden">foobar</div> establishes both inline and block formatting context (inline wins though).

• layout/layouttree/LayoutBox.h: establishesBlockFormattingContext() does not need to be virtual since we can determine it by looking at the box's style. -while in case

of inline formatting context, it is about the content.

6:10 AM Changeset in webkit [234082] by Yusuke Suzuki

• 26 edits in trunk/Source

[JSC] Use Function / ScopedLambda / RecursableLambda instead of std::function
​https://bugs.webkit.org/show_bug.cgi?id=187472

Reviewed by Mark Lam.

Source/JavaScriptCore:

std::function allocates memory from standard malloc instead of bmalloc. Instead of
using that, we should use WTF::{Function,ScopedLambda,RecursableLambda}.

This patch attempts to replace std::function with the above WTF function types.
If the function's lifetime can be the same to the stack, we can use ScopedLambda, which
is really efficient. Otherwise, we should use WTF::Function.
For recurring use cases, we can use RecursableLambda.

• assembler/MacroAssembler.cpp:

(JSC::stdFunctionCallback):
(JSC::MacroAssembler::probe):

• assembler/MacroAssembler.h:
• b3/air/AirDisassembler.cpp:

(JSC::B3::Air::Disassembler::dump):

• b3/air/AirDisassembler.h:
• bytecompiler/BytecodeGenerator.cpp:

(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack):
(JSC::BytecodeGenerator::emitEnumeration):

• bytecompiler/BytecodeGenerator.h:
• bytecompiler/NodesCodegen.cpp:

(JSC::ArrayNode::emitBytecode):
(JSC::ApplyFunctionCallDotNode::emitBytecode):
(JSC::ForOfNode::emitBytecode):

• dfg/DFGSpeculativeJIT.cpp:

(JSC::DFG::SpeculativeJIT::addSlowPathGeneratorLambda):
(JSC::DFG::SpeculativeJIT::compileMathIC):

• dfg/DFGSpeculativeJIT.h:
• dfg/DFGSpeculativeJIT64.cpp:

(JSC::DFG::SpeculativeJIT::compile):

• dfg/DFGValidate.cpp:
• ftl/FTLCompile.cpp:

(JSC::FTL::compile):

• heap/HeapSnapshotBuilder.cpp:

(JSC::HeapSnapshotBuilder::json):

• heap/HeapSnapshotBuilder.h:
• interpreter/StackVisitor.cpp:

(JSC::StackVisitor::Frame::dump const):

• interpreter/StackVisitor.h:
• runtime/PromiseDeferredTimer.h:
• runtime/VM.cpp:

(JSC::VM::whenIdle):
(JSC::enableProfilerWithRespectToCount):
(JSC::disableProfilerWithRespectToCount):

• runtime/VM.h:
• runtime/VMEntryScope.cpp:

(JSC::VMEntryScope::addDidPopListener):

• runtime/VMEntryScope.h:
• tools/HeapVerifier.cpp:

(JSC::HeapVerifier::verifyCellList):
(JSC::HeapVerifier::validateCell):
(JSC::HeapVerifier::validateJSCell):

• tools/HeapVerifier.h:

Source/WTF:

• wtf/ScopedLambda.h:

(WTF::ScopedLambda<ResultType):