Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Set the lowest bit in object tags (#2801)
In compacting GC we need to distinguish a heap location (object or field address) from object headers. Currently this is done by checking if the value is smaller than or equal to the largest tag. Because first 64 KiB of the heap is for Rust stack, as long as the largest tag is smaller than 65,536, we can assume that values smaller than 65,536 are headers. This way of checking if a value is a header or an address causes problems when we want to use rest of the object headers to store more information. Examples: - In #2706 we will use one bit in the header to mark large objects. At least initially, we won't be compacting large objects, so mark-compact GC won't see large objects and so won't have to care about large header values. But we may want to do compaction on large objects, or store other information (maybe mark bits, or generation numbers). - We may want to store number of untagged (scalar) and tagged fields in object headers and merge some of the different object types. For example, instead of having 3 tags for `Variant`, `Some`, and `MutBox`, we could have one tag, and use rest of the headers to indicate that variants will have one scalar, one tagged fields, mutable objects will have just one tagged field, etc. - We could have `SmallBlob` and `SmallArray` types for blobs and arrays with lenghts smaller than 65,535 (16 bits length field). This would save us one word for small blobs and arrays. - We don't have to rely on Rust stack being large enough so that largest tag will still be small enough to be a valid address in heap. In this PR we update tags so that they always have the lowest bit set. Since objects and fields are all word aligned (so have the lowest 2 bits unset, this invariant was established in #2764), this allows checking the lowest bit to distinguish an address from a header. With this we can freely use the rest of the bits in headers. While this PR currently does not unblock any PRs, it's nice to have this flexibility for the future changes, and these changes do not have any downsides. (mo-rts.wasm grows 0.03%, 58 bytes)
- Loading branch information