If it's only polymorphism we're worried about, there's scenarios we could come up with where this actually reduces polymorphism (e.g. if there is an array access site which gets data sometimes from Array.fill, sometimes from array literals, right now it would be polymorphic and if we made this change it would stay monomorphic). I'd be more worried about correctness issues stemming from us assuming that elements kinds manifold are monotonic, e.g. due to HOLEY_ELEMENTS being a stable map.
On Wednesday, February 12, 2025 at 12:52:07 PM UTC+1 Jakob Kummerow wrote: > The latter increases polymorphism. As a general principle, V8 tries to > avoid flip-flopping of types/maps/etc; instead it prefers to settle into a > stable state as quickly as possible. That why so far, the rule has been > "once an array is holey, it'll stay holey forever". > > The former avoids the flip-flopping but is more difficult to accomplish. > If done partially (e.g. only in optimizing compilers with code dependencies > on pristine Array.prototype), it also increases polymorphism, as well as > risk of deopts. > > So the cost of increased polymorphism (and perhaps deopts) has to be > weighed against the (fairly minor) benefit of a few avoided hole checks. > I'd say some very careful benchmarking is in order to demonstrate that the > wins justify the additional complexity. > > > On Wed, Feb 12, 2025 at 11:22 AM Marja Hölttä <ma...@chromium.org> wrote: > >> Hi, >> >> I was wondering whether breaking the invariant "elements transitions >> always go from specific to generic" will break something. I don't know. But >> given that Vyacheslav proposed doing this, and nobody came up with >> objections detailing what will break, maybe it won't break anything? >> >> Is the goal to just optimize "Array(n).fill(something)" (that exact >> syntactic pattern) or more generally, make Array.prototype.fill transition >> to a more specific ElementsKind if certain conditions are met? >> >> >> On Mon, Feb 10, 2025 at 6:53 PM Benjamin Kietzman <beng...@gmail.com> >> wrote: >> >>> Currently, calling Array.fill will produce an array with HOLEY elements. >>> >>> > %DebugPrint(Array(1).fill(0)) >>> DebugPrint: 0000015DF1C8CF29: [JSArray] >>> - map: 0x00280f5cf721 <Map[32](HOLEY_SMI_ELEMENTS)> [FastProperties] >>> - prototype: 0x02f93035a851 <JSArray[0]> >>> - elements: 0x015df1c8cf49 <FixedArray[1]> [HOLEY_SMI_ELEMENTS] >>> - length: 1 >>> >>> This seems like a missed opportunity for optimization since the new >>> array could be upgraded to PACKED_SMI_ELEMENTS. There's a very old issue >>> about this https://issues.chromium.org/issues/42210138 which hasn't >>> collected any objections. >>> >>> I'd be a first time contributor to V8 but I'd be happy to try patching >>> this. All advice would be welcome! >>> >>> Ben Kietzman >>> >>> -- >>> >>> -- -- v8-dev mailing list v8-dev@googlegroups.com http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/v8-dev/4d2d29ac-e241-46eb-9eb0-f60ab164b7a6n%40googlegroups.com.
