Move to the Truffle Object Model #226

New Issue

adam · 2025-12-30T01:22:29+01:00

adam commented

2025-12-30 01:22:29 +01:00

Originally created by @KushalP on GitHub (Oct 22, 2024).

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.

Originally created by @KushalP on GitHub (Oct 22, 2024). The [Dynamic Object Model](https://www.graalvm.org/latest/graalvm-as-a-platform/language-implementation-framework/DynamicObjectModel/) APIs were introduced with GraalVM 20.2.0, and the [Static Object Model](https://www.graalvm.org/latest/graalvm-as-a-platform/language-implementation-framework/StaticObjectModel/) 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.

adam commented

2025-12-30 01:22:30 +01:00

@odenix commented on GitHub (Oct 24, 2024):

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)

@odenix commented on GitHub (Oct 24, 2024): 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](https://www.graalvm.org/latest/graalvm-as-a-platform/language-implementation-framework/TruffleLibraries/). * Replacement of `java.lang.String` with [TruffleString](https://docs.oracle.com/en/graalvm/jdk/21/docs/graalvm-as-a-platform/language-implementation-framework/TruffleStrings/) * 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)

adam commented

2025-12-30 01:22:30 +01:00

@KushalP commented on GitHub (Oct 24, 2024):

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: https://github.com/apple/pkl/pull/683

@KushalP commented on GitHub (Oct 24, 2024): > 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: https://github.com/apple/pkl/pull/683

adam commented

2025-12-30 01:22:30 +01:00

@odenix commented on GitHub (Oct 24, 2024):

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.

@odenix commented on GitHub (Oct 24, 2024): > 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.

adam commented

2025-12-30 01:22:31 +01:00

@KushalP commented on GitHub (Oct 24, 2024):

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.

@KushalP commented on GitHub (Oct 24, 2024): > 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.

adam referenced this issue

2025-12-30 01:24:38 +01:00

[PR #226] [MERGED] Minor development/contributing/ci doc links / additions #462

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/pkl#226