It may be useful to consider use inline fields if the table is very small. For example:

@SuppressWarnings("deprecation")
class LuaSmallTable extends DynamicObject implements TruffleObject {
    @DynamicField Object field0;
    @DynamicField Object field1;
    @DynamicField Object field2;
    @DynamicField Object field3;
    LuaSmallTable(Shape shape) {
        super(shape);
    }
}

with this we can have a small dynamic object with 4 fields inlined. The identifier for the fields are then stored in the shape.

An object consists of two separate parts:

• the object storage, containing per-instance data,
• and the shape, which provides a mapping of member names to locations in the object storage (similar to a Java class).

Details:

• Primitive Area and Object Area are separate; the later one is managed by GC.

• Object is fixed sized. Use Extension Array for resize

• Shapes are immutable, but we can switch to a new shape.

• Locations are final andvolatile

• Root of a shape is empty

• Transitions:

  • Add property
  • Delete property
  • Change attribute
  • Change storage location
  • Transitions are acyclic. (covariant)

Implementation

• Annotation: @DynamicField

• Need to decide: How many primitive/object fields should be provided.

• Shapes use hidden classes, more friendlier to the guest languages with less runtime property changing.

  In special cases, one can store the shape in Hashmap.

Memory Issue

• The transition map uses SoftReferences for successor shapes, so that they can be released by the garbage collector under memory pressure

• The properties collection in a shape is created lazily and only when actually used. It can be reconstructed (recursively) from the property collection of the predecessor shape by applying the changes of the transition that lead to this shape.

• The system handles extremely large objects by de-grading to a fallback representation based on a hash table that does not require any shapes

see oracle/graal#2505.