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

Forward-declaring section sizes #10

Open
tlively opened this issue Feb 5, 2020 · 4 comments
Open

Forward-declaring section sizes #10

tlively opened this issue Feb 5, 2020 · 4 comments

Comments

@tlively
Copy link
Member

tlively commented Feb 5, 2020

In #5, @kmiller68 raised the issue that in the presence of conditional contents, the engine no longer knows up front how much space to allocate for the vectors that make up the module. It's unclear how much of a problem engine implementors consider this to be, so I would like to gather feedback here on whether it's worth adding a mechanism to forward declare section sizes.

@lars-t-hansen
Copy link

We pre-reserve space for section contents as we reach each section and read the count of section elements, but from glancing over the code it doesn't look like it would be a big hardship to have to deal with multiple section fragments.

A mildly interesting problem is that we reserve space for the machine code based on knowledge of the size of the bytecode and empirical data about the ratio of machine code to byte code; this is a performance win for the baseline compiler (less copying for buffer resizing; quicker load). With multiple code sections this will break down, as we don't want to read all the bytecodes before we start compiling.

@devsnek
Copy link
Member

devsnek commented Feb 12, 2020

What if instead of making the entire section conditional, individual elements of the section were conditional. For example in the type section, you have to provide n types, but some of those types would be wrapped in conditions, having to select one thing or the other.

@tlively
Copy link
Member Author

tlively commented Feb 13, 2020

@devsnek One of the limitations of that approach is that you can no longer have different numbers of elements depending on features (which is of course solves this forward declaration problem). I think one of the things we need to figure out is how important it is to allow different feature sets to have different numbers of elements. If we decide that's not important, we can take a look at simplifying the design in one way or another.

@devsnek
Copy link
Member

devsnek commented Feb 13, 2020

Indeed. I think it's worth noting the biggest implication of that is possibly having to emit unused stubs for the case where an element wouldn't be needed. I agree we need to better figure out our needs.

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

3 participants