deps: V8: cherry-pick ca5b0ec

[addaleax]

Original commit message:

[heap] Ensure SyntheticModule is initialized before next allocation

Ensure that all fields of `SyntheticModule` are set before creating
the exports hash table for it, because the latter may trigger
garbage collection, leading to crashes.

This has been causing failures in the Node.js CI over the last weeks,
after making the creating of synthetic modules part of Node’s
startup sequence.

(I am generally not very familiar with this part of the V8
code and there might be a better way, or possibly a way to add a
reliable regression test, that I am not aware of.)

Refs: https://github.com/nodejs/node/issues/30498
Refs: https://github.com/nodejs/node/issues/30648
Change-Id: I32da4b7bd888c6ec1421f34f5bd52e7bad154c1e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1939752
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65247}

Refs: v8/v8@ca5b0ec
Fixes: #30498
Fixes: #30648

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• commit message follows commit guidelines

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/27151/ ✅
V8 CI: https://ci.nodejs.org/job/node-test-commit-v8-linux/2662/

[addaleax]

👍 this comment to approve fast-tracking, this fixes a flaky test in CI that has been very unstable this week.

[gireeshpunathil]

new v8 CI: https://ci.nodejs.org/job/node-test-commit-v8-linux/2663/

[targos]

@gireeshpunathil V8 CI is as good as it can be. There are two permanent red jobs because of #30152.

[gireeshpunathil]

ah, ok. so landing...

[gireeshpunathil]

landed as 58850f6 and 29b5432

[addaleax]

@gireeshpunathil Just so you know, the commit message for the second commit was just fine – our tooling has special handling for the standard git revert format, so it would have highlighted that the commit was a revert but otherwise have handled it correctly.

Also, I think some indentation was lost for the first one?

[gireeshpunathil]

@addaleax - this is what I got with the core-validate-commit . So I just adjusted things such that it does not complain!

did not know that the tooling will take care of those stuff. Is there anything needs to do now, or is it just ok?

#git rev-list upstream/master...HEAD | xargs core-validate-commit
  ✖  1a46b7ccd7b786a990b80413792db66b1bbc1aad
     ✔  0:0      skipping fixes-url                        fixes-url
     ✔  0:0      blank line after title                    line-after-title
     ✔  0:0      line-lengths are valid                    line-length
     ✔  0:0      metadata is at end of message             metadata-end
     ✔  0:0      reviewers are valid                       reviewers
     ✔  0:0      valid subsystems                          subsystem
     ✖  0:50     Title must be <= 50 columns.              title-length
  ✖  dcc885f9b3c269bc0f78c288898214b7f90465f2
     ✔  26:7     Valid fixes url                           fixes-url
     ✔  27:7     Valid fixes url                           fixes-url
     ✔  0:0      blank line after title                    line-after-title
     ✖  9:72     Line should be <= 72 columns.             line-length
     ✖  20:72    Line should be <= 72 columns.             line-length
     ✖  25:72    Line should be <= 72 columns.             line-length
     ✔  0:0      metadata is at end of message             metadata-end
     ✔  0:0      reviewers are valid                       reviewers
     ✔  0:0      valid subsystems                          subsystem
     ✔  0:0      Title is <= 50 columns.                   title-length

[addaleax]

I think it’s fine, I just wanted to let you know :)

That being said, I think your local version of core-validate-commit might be out of date? I think all of these issues have been fixed by now.

[gireeshpunathil]

thanks; between this conversation I guessed so (out-dated tooling).