Upcoming changes to the LLCPP API to support inlining in union and table fields

[Benjamin Prosnitz]

This is an informational message about an upcoming LLCPP migration.

It is optional to read - all migration work will be performed by the FIDL team.

There are upcoming changes to the way that union and table fields are represented in-memory in LLCPP to match recent changes to the underlying wire format. This means the following changes will be made to the LLCPP API:

Changes to Table API

Fields will be assigned in one of two different ways depending on the size of the content.

Setting fields > 4 bytes in size: (currently used for all values regardless of size)

T& set_my_field(::fidl::ObjectView<uint64_t> elem);

Setting fields <= 4 bytes in size:

T& set_my_field(uint32_t value);

Changes to Union API

Resource unions will be move-only. Non-resource unions can still be moved or copied.

Fields will be assigned in one of two different ways depending on the size of the content.

Setting fields > 4 bytes in size: (currently used for all values regardless of size)

void set_my_field(::fidl::ObjectView<uint64_t> val);

Setting fields <= 4 bytes in size:

void set_my_field(uint32_t val);

Motivation

RFC-0114 proposed a wire format change that introduces a mechanism to inline value <= 4 bytes in size into envelopes, the structure used to store FIDL union and table fields. LLCPP uses an in-memory representation closely matching the FIDL wire format and is designed for efficient access to these structures. The new assignment API allows efficient access to inlined fields and the ability to avoid an allocation that otherwise would be needed.

Benjamin Prosnitz | Software Engineer | bpro...@google.com | 917-293-4452

[Yifei Teng]

On Fri, Sep 3, 2021 at 2:58 PM 'Benjamin Prosnitz' via fidl-dev <fidl...@fuchsia.dev> wrote:

This is an informational message about an upcoming LLCPP migration.

It is optional to read - all migration work will be performed by the FIDL team.

There are upcoming changes to the way that union and table fields are represented in-memory in LLCPP to match recent changes to the underlying wire format. This means the following changes will be made to the LLCPP API:

Changes to Table API

Fields will be assigned in one of two different ways depending on the size of the content.

Setting fields > 4 bytes in size: (currently used for all values regardless of size)

T& set_my_field(::fidl::ObjectView<uint64_t> elem);

Setting fields <= 4 bytes in size:

T& set_my_field(uint32_t value);

Just to clarify, this is the API that would've been generated if |value| was of type |uint32_t|, and we'd generate other more specific types if |value| was a bits or enums etc?

 

Changes to Union API

Resource unions will be move-only. Non-resource unions can still be moved or copied.

Fields will be assigned in one of two different ways depending on the size of the content.

Setting fields > 4 bytes in size: (currently used for all values regardless of size)

void set_my_field(::fidl::ObjectView<uint64_t> val);

Setting fields <= 4 bytes in size:

void set_my_field(uint32_t val);

Motivation

RFC-0114 proposed a wire format change that introduces a mechanism to inline value <= 4 bytes in size into envelopes, the structure used to store FIDL union and table fields. LLCPP uses an in-memory representation closely matching the FIDL wire format and is designed for efficient access to these structures. The new assignment API allows efficient access to inlined fields and the ability to avoid an allocation that otherwise would be needed.

Benjamin Prosnitz | Software Engineer | bpro...@google.com | 917-293-4452

--
All posts must follow the Fuchsia Code of Conduct https://fuchsia.dev/fuchsia-src/CODE_OF_CONDUCT or may be removed.
---
You received this message because you are subscribed to the Google Groups "fidl-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fidl-dev+u...@fuchsia.dev.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/fidl-dev/CAFeT2miORpX5gTSi43Jx4nY6YXn1BNn6PV4cnPjEJLCHMbbr9w%40mail.gmail.com.

[Benjamin Prosnitz]

Yes, uint32_t and uint64_t are just examples of types that are <= 4 bytes and > 4 bytes respectively. An analogous interface will be used for other types.

Benjamin Prosnitz | Software Engineer | bpro...@google.com | 917-293-4452