-
Notifications
You must be signed in to change notification settings - Fork 30k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
build: build v8 with -fvisibility=hidden on macOS #56275
base: main
Are you sure you want to change the base?
Conversation
Review requested:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Impressive catch, thank you.
Rubber stamp LGTM
Looks like great work! Congratulations! |
b8c972d
to
970f133
Compare
Updated to also apply the flag to Linux. The performance profile on Linux stays the same since Linux didn't have that regression in the first place, though this does shrink the binary by about 8MB. |
970f133
to
7021192
Compare
Added BUILDING_V8_SHARED to fix the addon tests since we'll now need V8_EXPORT to explicitly mark the symbols as visible. |
Someone should give Joyee an award for this PR. |
I want to approve this PR multiple times just to show my respect. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
V8 should be built with -fvisibility=hidden, otherwise the resulting binary would contain unnecessary symbols. In particular, on macOS, this leads to 5000+ weak symbols resolved at runtime, leading to a startup regression. On macOS this also reduces the binary size about ~10MB. It's only enabled on macOS in this patch as gcc can time out or run out of memory on some machines in the CI with -fvisibility=hidden.
7021192
to
3b1bdd4
Compare
It seems on some Linux configs and on SmartOS, with |
tools/v8_gypfiles/v8.gyp
Outdated
'GCC_SYMBOLS_PRIVATE_EXTERN': 'YES', # -fvisibility=hidden | ||
}, | ||
'defines': [ | ||
'BUILDING_V8_SHARED', # Make V8_EXPORT visible. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lines 478 to 479 in 5a868b5
'BUILDING_V8_SHARED=1', | |
'BUILDING_UV_SHARED=1', |
common.gypi
probably needs to be consolidated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think for addons, common.gypi
should define USING_V8_SHARED
instead, then in node.gypi
we need to undefine it/override it to BUILDING_V8_SHARED
when building libnode, though that might be a bit challenging to get right with the messy gyp config inheritance all over the place..for now there should probably not even be any difference on Windows (USING_V8_SHARED
only affects Windows AFAICT, but currently both the addons and the Node.js build have BUILDING_V8_SHARED
on Windows before and after this PR, even though it's technically not quite right for the addons to do that - not that it's going to be buggy, just less optimized). We can look into it in a follow up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, agreed that addons should have USING_V8_SHARED
defined. Right now, it is defined in node-gyp. So here in common.gypi, it may be removed in a follow-up.
https://github.com/nodejs/node-gyp/blob/b899faed56270d3d8496da7576b5750b264c2c21/addon.gypi#L36
It seems non-macOS platforms are still timing out, likely due to ccache invalidation (#56290 (comment))? So I changed the config to completely scoped to macOS in this PR - for non-macOS updates I will find a time when the CI is less busy to work on it in #56290 |
V8 should be built with -fvisibility=hidden, otherwise the resulting binary would contain unnecessary symbols. In particular, on macOS, this leads to 5000+ weak symbols resolved at runtime, leading to a startup regression.
On macOS this also reduces the binary size about ~10MB. On Linux the size reduction is around 8MB.
On Linux the performance is mostly the same as Linux's ld doesn't resolve the weak symbols like macOS's dyld does in the first place, so there was no regression to fix. This does however makes the binary a bit smaller. EDIT: split out the non-macOS settings to #56290 since it seems to cause gcc to time out or run out of memory on some machines in the CI, possibly because it invalidates the ccache on too many machines.
Fixes: nodejs/performance#180