Page History

...

• FIeld IDs and lengths are moved to object footer.
• Relative footer offset is added to object header.
• All field IDs are hashed in order they are written. Resulting value is saved to object header. We refer to is as *schema ID*.

Resulting object layout (unrelated header pieces are ommited):

...

[Y+8 .. Y+12] - Field 2 ID, etc.

Implementation details

Object schema

We define each unique set of written fields as schema. The following example demonstrates two schemas:

void writePortable(PortableWriter w) {
    w.write("A", a);
    w.write("B", b);
 
    if (b) 
        w.write("C", c); // Schema 1: [A->B->C];
    else
        w.write("D", d);'// Schema 2: [A->B->D];
}

Each schema consists of:

• Schema ID which is a hash of all field IDs. E.g. ID =  HASH("C" + HASH("B" + HASH("A")));
• Total fields count;
• (string, fieldId) pairs.

Known schemas are stored in read-only structure. If new schema is detected during read or write, it is updated atomically. Normally object will have only 1 schema, 2-3 schemas in rare cases, >3 schemas in very rare cases. For this reason we can store them in volatile array or so.

Schemas are stored inside existing type descriptor. This way we avoid additional hash map lookups.

Object write

• We save object field IDs and offsets to array during write. When all fields are written, we simply copy this array to object footer in a single System.arrayCopy() or Unsafe.copyMemory() operation. To minimize GC garbage we can use thread-local array instead of "new byte[]";
• If new schema is detected at the end of object write, it is added to the list of known object schemas.
• If collision is detected on (schema ID, fields count) pair, we throw an excpetion in the same way as if we had field ID conflict. This should be very unlikely event. N.B.: we can support collisions with some additional computational overhead.

Object read

• First of all we check if object's schema is known. If no, we scan the whole object, create the schema and save it. Normally this will require only 1-2 int comparisons;
• Field name is converted to field ID as usual;
• Schema is queried for footer offset for this field ID. We need to evaluate possible techniques for fast int lookup: normal HashMap, open-addressing like in ThreadLocal's, specialized int-int maps. Anyways, even HashMap should usually sustain 0(1) complexity;
• Go to footer and get field offset: FieldOffset = valueOf(FooterOffset + SchemaFieldIdOffset);
• Use FIeldOffset to get the field.