When I change the type of ExtremumLength to somthing like:

pub enum GenericExtremumLength<LengthPercent> {
    #[parse(aliases = "-moz-max-content")]
    MaxContent,
    #[parse(aliases = "-moz-min-content")]
    MinContent,
    MozFitContent,
    MozAvailable,
    FitContentFunc(LengthPercent),
}

This makes StyleSize and StyleMaxSize become 24 bytes (note: the original size is 16 bytes). The total size of nsStylePosition becomes 520 bytes, which is larger than 512 bytes. Perhaps need to figure out a way the make nsStylePosition smaller. Just reordering the struct members to reduce the memory padding doesn't help a lot for now.

Probably box some uncommon properties first?

Based on the update of ExtremumLength (comment 0), the sizes of the data members in nsStylePosition:

If you put fit-content in GenericSize / GenericMaxSize it shouldn't grow. Would that work? The reason they're in a separate enum is kind of ad-hoc anyways, ExtremumLength doesn't signify anything. So we could also just derive(Parse) and put the keywords directly in Size / MaxSize.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #3)

If you put fit-content in GenericSize / GenericMaxSize it shouldn't grow. Would that work? The reason they're in a separate enum is kind of ad-hoc anyways, ExtremumLength doesn't signify anything. So we could also just derive(Parse) and put the keywords directly in Size / MaxSize.

Yes. This makes sense. Thanks for file the bug. :)

(In reply to Xidorn Quan [:xidorn] UTC+11 from comment #1)

Probably box some uncommon properties first?

Yes. This should be a quick way. Most of the large data members are related to grid and size, so perhaps need to box others. Otherwise, we need to make sure the the large data members not grow too much.

Another option is to consider make StyleSize more compact. I don't think it's common case (either a pixel number or a percentage or auto) need 3 words. Maybe we can make them a compact pointer, for example, having the last two bits being the enum tag, and box all other cases. I think StyleSize should be common enough to be worth this special handling.

We use that trick for LengthPercentage already, so StyleSize now (and after bug 1695390) would be just one word plus the 8-bit tag plus padding. I don't think we can fit all the other keywords in the remaining LengthPercentage bits so it seems it's as good as we can make it for now...

Okay I think two words size is reasonable. It's probably hard to go down further.