# Efficient Data Exchange between WebAssembly Modules
## 4 Karmem Approach
### Data Layout
#### 4.2.4 Evolution  
Typically, the evolution of structures is not a concern for compiled languages without an IPC requirement, since types are well-known at the time of compilation and only consumed by the application itself. However, for Karmem, it is possible to have multiple versions of the same definition, all of which must be able to communicate seamlessly across multiple applications. Changing an existent structure usually changes paddings and distances between each field in an array or demands the usage of pointers and indirect access. The construction of dynamic structures may impose performance issues since each structure can have an unknown internal layout. The strategy employed by FlatBuffers is to use one pointer to an internal lookup table for each structure. This can be useful for omitting unused fields and reducing the space required for the serialization format. However, it introduces new steps, prevents the usage of SIMD instructions, and can populate the CPU cache with unnecessary data. Karmem takes advantage of SoA, which enforces a consistent memory layout and a single lookup table. It requires only three bound checks independent of the number of items in one array. This allows the program to take advantage of SIMD while fully ignoring the existence of newer fields. In this case, a single table lookup is responsible for returning a pointer of an array of homogenous-type data (numbers). Dynamic structs can store different types of data and can be modified by adding new fields at the end, thereby maintaining backward compatibility with previous versions. This functionality is implemented by checking the size of the structs and comparing it with the offset of the data to be read. However, checking the size of each item in one large array can be inefficient; this is how Cap'n'Proto works. Figures 8-10 demonstrate this functionality by adding new fields while preserving compatibility with previous versions. Although this technique is widely used for IPC, it requires the use of pointers, which can cause inefficiencies in data access, especially in the case of arrays. When dealing with a single struct, there is only one offset to access that single struct, as shown in Figure 11. The total size is stored in 29 bits, while the remaining three bits store the unused space (up to seven bytes). By applying delta encoding, the used value can be determined based on the total size (which is always multiplied by eight bytes): (size_total \(\times\) 8) - size_wasted. Figure 8: Struct dynamic example, version 1. Figure 10: Struct dynamic example, version 3. Figure 9: Struct dynamic example, version 2. Assuming the data definition in Figure 4, which has 16 bytes with 10 bytes used, it would result in Figure 12.  
If the structure is used in a SoA, it is represented by an additional structure containing the offsets of each vector. All offsets are always multiplied by 512 bits, as shown in Figure 14.  
To maintain compatibility and support for structure evolution, an auxiliary lookup structure was created. The lookup consists of two arrays: one for the hash and another for the respective offsets of each array. The hash considers the position of each element defined in the struct, following one hash-chain for flattening structs, to ensure stability regardless of modifications to other intermediate structs. Karmem uses a linear search to find the entry point of each array in the SoA. This linear search is optimized with SIMD, when possible, to drastically reduce the number of required comparisons. Therefore, such arrays are always a multiple of 64 bytes, which enables the use of AVX512. The hash value is limited to 4 bytes, allowing up to 16 comparisons per loop. Once a matching hash value is found, it retrieves the pointer, as shown in Figure 15. To prevent malicious crafted message to exhaust resources with large linear search, a maximum number of fields can be defined. This limitation can cause legitimate messages to be invalidated if the threshold is too tight.