The last part is correct; layouts are not GC'd objects. They are views over byte arrays (or mmap'd memory, or unsafe regions like the execution stack). The firs

The last part is correct; layouts are not GC'd objects. They are views over byte arrays (or mmap'd memory, or unsafe regions like the execution stack). The first part is partially incorrect; layouts are not "boxed"--they are represented underneath as a pair of a (potentially null) GC object and a pointer-sized offset into that object. So with that representation you can have a reference to an off-heap layout as well. Layouts are a little underpowered right now, owing mostly to the conservatism in that they could always be aliased by a byte array or any other alias, thus their bytes are chaos-bits that cannot be trusted. Adding the ability to have pointers between layouts is another level; for that, I am envisioning reads of pointers requiring a second capability which is the expected region into which the pointers lie. But all of the layout stuff is fundamentally not about performance, it's about interfacing with external software and hardware. In Virgil the expectation that you should use the good, type- and memory-safe constructs like classes, arrays, tuples, ADTs, etc. These are plenty efficient and getting new annotations to control their representation in a more fine-grained way.