[vm/ffi] `@Constant` for compile-time null terminated strings

[ds84182]

Would be nice to have to avoid managing allocations for C strings, and in AOT it could be part of the .rodata section of the executable.

Would support UTF-8 (Uint8) and UTF-16 (Uint16). Could be extended for value and struct constants behind a pointer as well.

@Constant('Hello, World!\n')
external Pointer<Uint8> get greeting;

puts(greeting);

// Or maybe...?
const greeting = Constant<Pointer<Uint8>>('Hello, World!\n');

puts(greeting.ptr);

cc @dcharkes

[dcharkes]

That's an interesting idea.

When addressing https://github.com/dart-lang/sdk/issues/47718, we should get the right infrastructure to do this.

Though, how do we provide an API for JIT in this case? Do we in JIT allocate at runtime and leak?

And maybe we can try to align the syntax with https://github.com/dart-lang/sdk/issues/50551.

// Global var in native asset, similar to `@Native external` function.
@NativeSymbol(/* optional symbol and asset */); // No type argument, as the Pointer already has it.
external Pointer<Uint8> get greeting;

// Global var in Dart.
@Constant('Hello, World!\n')
external Pointer<Uint8> get greeting;

Maybe if we address https://github.com/dart-lang/sdk/issues/50565 and https://github.com/dart-lang/sdk/issues/50551, we can just put them in a src/constants.c instead. Is there a strong preference for having them in Dart?

[ds84182]

My preference for having them in Dart is mostly reducing the need to alloc & copy strings to the heap. It's a pain to manage temporary allocations for string-heavy APIs. A good example is Vulkan, where you have to look up all your functions using an instance-provided lookup function.

For JIT, the strings could live as long as the VM. Might require interning with a string cache of some kind.