deps: V8: cherry-pick 0f024d4e66e0

[IlyasShabi]

Original commit message:

[heap profiler] Add is_live field to AllocationProfile::Sample

When using kSamplingIncludeObjectsCollectedByMajorGC/MinorGC flag, samples for collected objects are retained but callers had no way to distinguish live from dead objects.
Add is_live to expose this information.

Change-Id: I2e930644348ff942caa4b192a127c5baa05bbfef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7603535
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#105698}

Refs: v8/v8@0f024d4

Motivation and changes

Continues the heap profiler improvements started in #62201 and #62273.

V8's StartSamplingHeapProfiler accepts GC flags that retain samples even after the objects are GC'd. However, there was no way to distinguish whether a sampled allocation was still alive or had already been freed.

With this commit, we can:

• Compute allocated vs freed memory
• Identify functions causing GC pressure due to high allocation and more..

As a follow-up, SerializeHeapProfile will be updated to include per-node freed object size based on is_live field from GetSamples().

[nodejs-github-bot]

Review requested:

• @nodejs/gyp
• @nodejs/security-wg
• @nodejs/v8-update

[targos]

Is this ABI-compatible?

[IlyasShabi]

Is this ABI-compatible?

This is ABI compatible since the commit adds a new field bool is_live at the end of the AllocationProfile::Sample struct. Node.js already consumes GetSamples() in src/node_worker.cc

[IlyasShabi]

@Qard @targos could you please check this PR again?

[targos]

My understanding of structs is that adding fields cannot be ABI-compatible because it changes the size of the object. @nodejs/cpp-reviewers

[IlyasShabi]

Yes the struct size does matter for ABI compatibility. But AllocationProfile::Sample is never constructed by Node.js, V8 creates and owns them internally. we only reads fields from the returned samples in src/node_worker.cc so adding a field here is safe.

[joyeecheung]

Our V8 header and all the symbols are exposed, so regardless of whether Node.js uses them internally, user land addons can already rely on them (and I think there are probably a long tail of addons or libraries that do, e.g. #61102, note that we don't use the default platform internally)

[IlyasShabi]

That's clear! I understand now how backporting in a patch release could break addons.
Would it make sense to include this cherry pick in #61898 where ABI changes are already expected maybe?