This repository was archived by the owner on Dec 7, 2024. It is now read-only.
Repository navigation
This repository was archived by the owner on Dec 7, 2024. It is now read-only.
Forward-declaring section sizes #10
Description
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.
Activity
lars-t-hansen commentedon Feb 7, 2020
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 commentedon 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 commentedon 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 commentedon 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.