When tracking type representations in ion, we use the TypeRepresentationSet abstraction, which basically encapsulates a list of canonical type abstractions. The set supports queries like "what is the offset of field foo" that will then be checked against every type repr in the set. This permits us to handle situations where you have multiple types flowing in that share common properties (a set of structs with a common prefix, for example). This approach is simple but has the downside that as the set grows larger, it requires more memory, but in fact the amount of usable information it represents gets smaller. For example, as you add more struct types to a set, the size of the set grows but the number of fields common to all types can only get smaller. A better approach would be to compute a least-upper-bound (in other words, track the common prefix of fields, to carry on with my example). There are some minor complications, and in the case of a singleton set we would just want to track the precise type representation, but that's the basic idea.

Assuming p5 because it's related to typed objects; although I wonder if this applies also to unboxed objects. I can't find any reference to TypeRepresentationSet, so this might have been renamed or disappeared. Brian, maybe do you know what it was renamed to, or what happened to TypeRepresentationSet?

TypeRepresentationSet was probably removed when I rewrote the JIT compilation code for typed objects. The idea in this patch applies to typed objects and unboxed objects and even normal native objects, but any changes here would need to be motivated by user data / test cases I think and since TypeRepresentationSet is gone it's probably better to do things in a new bug.