Skip to content
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

Minimal library that bootstraps #1160

Closed
iapaddler opened this issue Oct 24, 2022 · 3 comments
Closed

Minimal library that bootstraps #1160

iapaddler opened this issue Oct 24, 2022 · 3 comments
Assignees
Labels

Comments

@iapaddler
Copy link
Contributor

No description provided.

@jrcheli
Copy link
Contributor

jrcheli commented Nov 28, 2022

It'd be possible to break libscope.so into pieces, but I'm not sure we'd get as much benefit as we'd hope. I assume the desire here is to make sure we're being responsible with our resource utilization, even if our library is loaded but not actively producing data.

If memory utilization is the primary reason this is being considered, some nuances of linux come into play:
o) Our library is a shared library, so if a machine has one process that uses our whole library or a hundred processes that use our library, the memory utilization will be similar.
o) With memory virtualization, memory alloc'd by the library does will not consume any physical memory until the process actually writes to memory (by increments of pages). If our library isn't active, it won't use many pages of physical memory, even if the library were to request a lot of virtual memory.

If the concern is the linking and loading time... w.r.t. linking time, the recent change toward got-hooking (#1039) should mean that we're not publishing many symbols any more, so the library's effect on linking time should be insignificant. w.r.t. loading, the largest segments of the library would simply be mapped into virtual memory so the load time would be very minimal.

If the concern is "unnecessary functionality" that some processes use and others don't... we have a small amount of code to handle technology-specific aspects of processes (go, java), but not enough to offer a meaningful savings if we refactored for this. Almost all of the code to support our two platforms (x86_64 and arm64) is already only built into the appropriate platform-specific build. Code to support TLS encryption isn't always configured to be used, but we've had earlier discussions where we decided not to have dependencies on external libraries if at all possible.

@iapaddler iapaddler moved this from Todo to In Progress in AppScope 1.3.0 (Spring) Feature Release Nov 29, 2022
@iapaddler iapaddler moved this from In Progress to In Review in AppScope 1.3.0 (Spring) Feature Release Nov 29, 2022
@seanvaleo
Copy link
Collaborator

seanvaleo commented Nov 29, 2022

Also: If the concern is visibility of libscope in the proc/*/maps file, adding a minimal library is not going to change the number of entries in the maps file; and will double the number of entries in the maps file of a scoped process.

@jrcheli
Copy link
Contributor

jrcheli commented Nov 29, 2022

I'm closing this with no action at the current time.

@jrcheli jrcheli closed this as completed Nov 29, 2022
Repository owner moved this from In Review to Done in AppScope 1.3.0 (Spring) Feature Release Nov 29, 2022
@iapaddler iapaddler moved this from Done to In Progress in AppScope 1.3.0 (Spring) Feature Release Jan 7, 2023
@iapaddler iapaddler moved this from In Progress to Done in AppScope 1.3.0 (Spring) Feature Release Jan 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
No open projects
Development

No branches or pull requests

3 participants