Producing PACKED arrays with Array.fill

139 views
Skip to first unread message

Benjamin Kietzman

unread,
Feb 10, 2025, 12:53:13 PMFeb 10
to v8-dev
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

Marja Hölttä

unread,
Feb 12, 2025, 5:22:40 AMFeb 12
to v8-...@googlegroups.com
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?


--
--
v8-dev mailing list
v8-...@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+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/v8-dev/77180799-00e5-402b-b99d-727039dc409cn%40googlegroups.com.


--


Google Germany GmbH

Erika-Mann-Straße 33

80636 München


Geschäftsführer: Paul Manicle, Liana Sebastian.

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg


Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.

    

This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.

Jakob Kummerow

unread,
Feb 12, 2025, 6:52:07 AMFeb 12
to v8-...@googlegroups.com
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.

Leszek Swirski

unread,
Feb 12, 2025, 10:08:29 AMFeb 12
to v8-dev
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.

Benjamin Kietzman

unread,
Feb 18, 2025, 2:40:45 PMFeb 18
to v8-...@googlegroups.com
I was thinking of making the change to Array.prototype.fill, and that if correctness issues arose I could try introducing a new array state just for empty arrays to recover element kind monotonicity, something like:

%DebugPrint(Array(100))
DebugPrint: 0000015DF1C8CF29: [JSArray]
 - map: 0x00280f5cf721 <Map[32](EMPTY)> [FastProperties]

However I get the impression this isn't #good-first-issue material

You received this message because you are subscribed to a topic in the Google Groups "v8-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/v8-dev/AmK_zmyHvFU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to v8-dev+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/v8-dev/4d2d29ac-e241-46eb-9eb0-f60ab164b7a6n%40googlegroups.com.

Leszek Swirski

unread,
Mar 5, 2025, 11:25:37 AMMar 5
to v8-dev
I agree that it's not good first bug material -- I went ahead and did it, and it did have a couple of little subtleties.
Reply all
Reply to author
Forward
0 new messages