When the interpreter has to copy the payload of a value class instance from one container to another one, it uses the AccessAPI. The AccessAPI ends up calling this method:

void Copy::conjoint_memory_atomic(const void* from, void* to, size_t size) {
  uintptr_t bits = (uintptr_t) from | (uintptr_t) to | (uintptr_t) size;

  // (Note: We could improve performance by ignoring the low bits of size,
  // and putting a short cleanup loop after each bulk copy loop.
  // There are plenty of other ways to make this faster also,
  // and it's a slippery slope. For now, let's keep this code simple
  
  // since the simplicity helps clarify the atomicity semantics of
  // this operation. There are also CPU-specific assembly versions
  // which may or may not want to include such optimizations.)

  if (bits % sizeof(jlong) == 0) {
    Copy::conjoint_jlongs_atomic((const jlong*) from, (jlong*) to, size / sizeof(jlong));
  } else if (bits % sizeof(jint) == 0) {
    Copy::conjoint_jints_atomic((const jint*) from, (jint*) to, size / sizeof(jint));
  } else if (bits % sizeof(jshort) == 0) {
    Copy::conjoint_jshorts_atomic((const jshort*) from, (jshort*) to, size / sizeof(jshort));
  } else {
    // Not aligned, so no need to be atomic.
    Copy::conjoint_jbytes((const void*) from, (void*) to, size);
  }
}

The last case can cause some tearing issues that have been overlooked so far. Copying the payload byte per byte can lead to the tearing of char, short, int and float values, in addition to the know issue of long and double tearing. This byte per byte copy can also cause issues when the payload include a null marker for the payload itself.

An in-depth analysis of those tearing issues must be performed, in order to adjust the implementation of the Access API and the flattening policies.