In Blink's version of Oilpan, GCInfo objects would reside in .bss and
a table would translate between an index and the .bss address. Upon
retrieving a GCInfoIndex, the slow path merely passes a .bss pointer
to a slow path setup method to create the table mapping.

In cppgc, we set up GCInfo entries directly in the table. This is
slightly faster for actually using GCInfo objects as there's no
indirection between table and .bss, and it also saves one pointer (the
indirection) per type that is set up. The downside of this approach is
that individual components of a GCInfo objects, that are all
type-dependent, need to be passed to the conditional setup method.
Since GCInfo indices must be retrieved on each allocation, this
pollutes the fast path with additional instructions.

However, GCInfo components are actually known at compile-time for many
objects. In such cases, we can use a compile-time static dispatch to
encode the known parameters in different functions. This saves around
40KiB of memory on ChromePublic.apk and also creates a more compact
fast path for allocation.

Bug: chromium:1238884, chromium:1056170
Change-Id: Iedd809a8baefcc02f131d2b2c77d341b0abe43bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3094007Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76291}