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

Better support for optional spaces #1173

Open
k-sareen opened this issue Jul 23, 2024 · 2 comments
Open

Better support for optional spaces #1173

k-sareen opened this issue Jul 23, 2024 · 2 comments

Comments

@k-sareen
Copy link
Collaborator

We should add better support for optional spaces inside plans. Here optional means Option<T> instead of conditional compilation like we have with VM space. Using optional spaces can be useful when you only want to allocate certain spaces when some command-line option has been set, for example.

@qinsoon
Copy link
Member

qinsoon commented Jul 23, 2024

Using optional spaces can be useful when you only want to allocate certain spaces when some command-line option has been set, for example.

Can you give an example when a binding needs to do this (they only know what space to use at run-time, not at build-time)?

If the cost of creating a space is cheap, why do we want to use Option<T> for a space rather than just creating a space and not using it? Do you propose to use Option<T> to replace the current conditional compilation for spaces?

@k-sareen
Copy link
Collaborator Author

So in Android, both the image space and Zygote are command-line options. If one doesn't provide the -Ximage:/path/to/image or -Xzygote options then it will never have an image space or attempt to create a Zygote space.

This is not a big deal for the image space since we can't actually allocate memory for it, but it is relevant to the Zygote space. I originally was implementing it like you said by always having a Zygote space and not using it when the command-line option was not passed, but I thought this would be better software engineering-wise to put the space behind an Option<T>.

If the cost of creating a space is cheap, why do we want to use Option for a space rather than just creating a space and not using it?

Because that requires trusting/ensuring the developer has not accidentally used the space. My stance has always been that something depending on developer discipline does not scale. So in such cases we should leverage Rust's type system to avoid making mistakes.

Do you propose to use Option to replace the current conditional compilation for spaces?

That's an interesting idea and I wasn't considering it (yet), but I think it might actually be cleaner in some ways than our current conditional compilation model.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants