Move to the Truffle Object Model

[KushalP]

The Dynamic Object Model APIs were introduced with GraalVM 20.2.0, and the Static Object Model APIs were introduced with GraalVM 21.3.0.

Using these Object Model APIs would be useful for caching, reducing safety checks, and improving profiling.

Note

Both of the above APIs are not compatible with each other.

[odenix]

A redesign of the interpreter's object model could explore the following topics:

• Multiple representations for the same type of object
  For example, different representations could be used for small, large, and surrogate listings.
  Truffle supports this via Truffle Libraries.
• Replacement of java.lang.String with TruffleString
• Thread safety
  A thread-safe object model could open the door to multi-threaded evaluation of Pkl code in the same Evaluator.
  As far as I know, code generated by Truffle is thread-safe.
• Support of elements and entries for typed objects (already supported for dynamic objects)

[KushalP]

Multiple representations for the same type of object

Agreed. As an extension to this it would be interesting to explore if Listing and List could be consolidated alongside Mapping and Map. This PR already tries to consolidate the APIs of these two structures, but it could go further with Truffle Libraries to have the "representation" choices around lazy vs. eager be modelled transparently: #683

[odenix]

As an extension to this it would be interesting to explore if Listing and List could be consolidated alongside Mapping and Map.

As of 0.26, Listing and List have very different semantics (late binding, etc.) and performance characteristics (lazy amendable object vs. eager persistent collection). Unless that changes (and maybe that's what you'd like to explore?), I don't think their internal representations can/should be unified.

[KushalP]

and maybe that's what you'd like to explore?

I'm purely trying to find ways to help. I'll leave that up to the Pkl team.